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EXECUTIVE  SUMMARY 


The  System  Support  Computer  Complex  (SSCC) ,  located  at  the  Federal  Aviation 
Administration  (FAA)  Technical  Center,  will  provide  centralized  support  for  all 
Advanced  Automation  System  (AAS)  development,  test,  evaluation,  deployment,  and 
maintenance  fimctions.  The  SSCC  is  evolved  in  four  consecutive  phases  to  support 
the  Implementation  of  the  four  different  segments  of  the  AAS.  These  segments  are 
the  Initial  Sector  Suite  System  (ISSS),  Tower  Control  Computer  Complex  (TCCC) , 
Terminal  Advanced  Automation  System  (TAAS) ,  and  the  Area  Control  Computer  Complex 
(ACCC) . 

This  version  of  the  SSCC  Operations  Concept  Document  discusses  the  SSCC-1  phase 
and  operation  aspects  for  the  ISSS  segment.  As  the  various  AAS  segments  are 
implemented,  this  document  will  be  updated  to  provide  the  reader  with  information 
relative  to  the  changes  from  the  previous  segment  upgrade. 

The  Technical  Center  will  be  the  support  hub  of  management,  maintenance,  and 
testing  of  AAS  software  and  hardware  configurations  for  all  AAS -equipped  ATC 
facilities  on  a  24-hour-a-day ,  7-day-a-week  basis.  The  following  Technical  Center 
organizations  play  major  roles  in  supporting  the  SSCC's  mission: 

a.  ACN-300,  Advanced  Automation  Systems  Division.  Provides  continued  support 
in  the  testing  of  new  developments  and  requirements  to  be  implemented  in  the  AAS  as 
approved  system  modifications. 

b.  ACN-400,  NAS  Facilities  Software  Engineering  Division.  Provides  software 
development.  Center  systems  maintenance,  enhancement  for  aircraft  target  simulation 
systems,  National  Airspace  System  (NAS)  operational  support  systems,  and 
engineering  computer  systems. 

c.  ACN-500,  NAS  Facilities  Hardware  Engineering  Division.  Plans,  manages, 
directs,  and  coordinates  the  technical,  electronic,  electrical,  and  digital 
engineering  for  the  Technical  Center  laboratories  and  facilities.  Also  provided 
are  the  technical  utilization,  maintenance,  modifications,  and  installation  of 
diversified  electronic  systems  and  facilities. 

d.  ACN-600,  NAS  Facilities  Operations  Division.  Provides  for  operation  of 
the  service's  Automated  Data  Processing  (ADP)  laboratories,  supporting  facilities, 
and  services  at  the  Technical  Center  required  by  all  Center  organizations,  AXD, 
contractors,  and  field  support  elements.  Also  performed  are  system  management 
functions  ensuring  efficient  use  of  equipment  to  meet  the  user -community 
requirements . 

e.  AOS -300/400,  Operational  Support  Services.  Provides  problem  resolution 
support  and  software  maintenance  services  to  the  field  sites. 

As  the  Technical  Center  takes  on  a  new  role  as  the  hub  for  centralized  maintenance , 
the  SSCC-1  will  become  the  central  repository  for  source  logic  and  Sector  Suite 
Adaptation  Data  for  20  Air  Route  Traffic  Control  Centers  (ARTCC) .  The  SSCC-1  will 
be  available  for  scheduled  use  by  all  organizations  conducting  testing  for  NAS 
programs . 
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It  is  envisioned  that  the  National  Automation  Engineering  and  Field  Support 
Division  (AOS)  organization  will  have  the  requisite  skills  and  resources  to  fulfill 
maintenance  responsibilities  after  the  expiration  of  IBM's  maintenance  contract. 

IBM  will  provide  maintenance  support  at  the  sites  for  the  first  year  on  a  24-hour- 
a-day  basis. 

In  AAS,  there  Is  still  a  unique  and  Important  role  that  cannot  be  performed  by 
Technical  Center  personnel,  and  this  Is  the  maintenance  of  the  local  site 
adaptation  data.  The  sites  remain  the  experts  and  sole  authority  over  their  local 
adaptation  data.  They  own  the  data,  they  are  qualified  In  its  use  and 
understanding,  and  they  are  solely  responsible  for  Its  continued  maintenance  and 
updating.  The  fact  that  the  databases  physically  reside  at  the  SSCC  and  do  not 
reside  at  the  sites  In  no  way  diminishes  or  limits  field  site  responsibility  for 
their  maintenance.  The  Engineering,  Test  and  Evaluation  Service  (ACN)  and  AOS 
organizations  will  continuously  work  together  in  the  support  of  the  field  sites  to 
maintain  an  efficient  system. 

The  field  site  personnel  have  the  capability  to  schedule  the  SSCC  to  test  and 
maintain  local  adaptation  data.  Field  sites  are  provided  with  remote  access  to 
SSCC  resources.  This  remote  SSCC  access  Is  used  for  problem  reporting,  adaptation 
data  maintenance,  hardware  symptom/flx  database  Inquiries,  generation  of 
appropriate  site  software  products,  and  other  related  maintenance  activities. 

Field  sites  will  not  have  a  site-resident  software  development  environment  and 
toolset  to  perform  software  development.  Software  maintenance  will  be  performed  by 
a  site  specialist  by  accessing  the  SSCC-resldent  databases  and  toolsets.  A  limited 
software  modification  capability  will  be  site -resident,  to  be  used  In  concert  with 
the  SSCC  to  address  emergency  corrections  to  ATC  software  logic. 

The  centralized  software  maintenance  concept  requires  field  site  personnel  to  work 
In  close  partnership  with  AOS  personnel  to  perform  national  adaptation  data 
updates,  and  solve  operational  hardware  and  software  problems.  AOS  personnel 
maintains  the  baseline  and  support  software,  and  the  national  adaptation  databases. 
AOS  will  be  available  24  hours  a  day,  7  days  a  week  to  resolve  field  site  problems. 
AOS  will  be  responsible  for  updating  national  adaption  data  for  all  ARTCCs.  Also, 
AOS  Is  responsible  for  providing  weekly  adaptation  updates  to  field  sites. 

The  SSCC-1  will  be  able  to  logically  replicate  the  ISSS  configuration  of  any  site. 
There  will  be  two  System  Support  Facilities  (SSF) ,  ISSS-1  and  ISSS-2.  The  primary 
use  of  the  SSFs  Is  to  replicate  ISSS  field  sites  In  order  to  update,  test,  and 
modify  source  software  logic  and  sector  suite  adaptation  data  changes.  ISSS-1 
and  ISSS-2  resources  will  be  available  for  scheduled  use  by  all  organizations  who 
conduct  testing  for  the  NAS,  which  Includes  ARTCC  personnel.  The  ISSS-1  and 
ISSS-2  will  be  maintained  by  ACN-400,  scheduled  as  a  resource  by  ACN-600.  A  new 
organization  will  be  established  for  Configuration  Management  (CM)  in  the  ACN 
Service . 

The  SSFs  will  enable  the  AOS  personnel  to  replicate  field  site  problems  and  aid  in 
problem  resolution  and  site-specific  testing.  Problems  found  and  reported  by  the 
site- resident  software  specialist  are  communicated  to  the  Technical  Center  for 
resolution.  This  is  done  informally  via  verbal  communications,  and  formally 
through  the  creation  of  a  problem  AAS  Change  Instrument  (ACI) .  Data  is  gathered  by 
the  site  specialists  to  assist  the  AOS  organization  with  problem  resolution. 

Through  the  cooperative  efforts  of  the  site  and  AOS  personnel ,  a  proposed 
resolution  is  identified. 
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As  required,  a  temporary  fix  or  procedural  work  around  is  developed  for  the 
immediate  use  of  the  site.  If  the  resolution  requires  modification  to  operational 
air  traffic  control  (ATC)  software,  a  logic  release  is  created,  introducing  the  fix 
as  a  source  change  at  the  SSCC.  The  modified  source  is  then  compiled  and  processed 
to  produce  an  output  product.  Following  the  necessary  binding  and  linking,  a 
resultant  load  module  is  generated.  Tests  are  run  on  the  SSFs  to  verify  the 
correctness  of  the  source -based  fix.  Upon  successful  completion  of  SSCC  testing, 
the  logic  release  is  packaged  into  a  system  release  for  site  installation  and  is 
then  made  available  for  deployment  (electronic  deployment  for  small  corrections  and 
updates).  Testing  and  certification  must  be  performed  at  the  site,  before  the  new 
system  release  is  made  available  for  operational  use  via  the  applicable  cutover 
procedures . 

By  the  first  ISSS  Operational  Readiness  Demonstration  (ORO) ,  which  is  in  Seattle , 
the  SSCC  will  be  able  to  support  software  functions,  hardware  functions,  firmware, 
CM,  and  maintenance  functions.  These  represent  the  minimum  fvmctional  requirements 
necessary  to  support  a  fielded  ISSS.  The  SSCC  will  at  that  time  consist  of  two 
ISSS  support  facilities  with  Common  Consoles  (CCs)  populated  with  Eagle  processors. 
The  HOST  processors,  Stand-Alone  Simulators  (SASs),  and  Peripheral  Adapter  Module 
Replacement  Items  (PAMRI)  are  shared  by  the  two  ISSSs.  In  addition,  the  AAS  Job 
Shop  will  have  been  validated  and  available  to  perform  SSCC  support  functions. 
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The  System  Support  Computer  Complex  (SSCC),  located  at  the  Federal  Aviation 
Administration  (FAA)  Technical  Center,  will  provide  centralized  support  for  all 
Advanced  Automation  System  (AAS)  development,  test,  evaluation,  deployment,  and 
maintenance  functions.  The  SSCC  is  evolved  in  four  consecutive  phases  to  support 
the  implementation  of  the  four  different  segments  of  the  AAS .  These  segments  are 
the  Initial  Sector  Suite  System  (ISSS),  Tower  Control  Computer  Complex  (TCCC) , 
Terminal  Advanced  Automation  System  (TAAS) ,  and  the  Area  Control  Computer  Complex 
(ACCC) .  Table  1-1,  SSCC  Phased  Implementation,  shows  the  correlation  of  each  AAS 
segment  to  .^ach  SSCC  phase. 


TABLE  1-1.  SSCC  PHASED  IMPLEMENTATION 


AAS  SEGMENT 

SSCC  PH*SE 

Initial  Sector  Suite  System  (ISSS) 

SSCC-1 

Tower  Control  Computer  Complex  (TCCC) 

SSCC-2 

Terminal  Advanced  Automation  System  (TAAS) 

SSCC-3 

Area  Control  Computer  Complex  (ACCC) 

SSCC-4 

This  version  of  the  SSCC  Operations  Concept  Document  discusses  the  SSCC-1  phase 
and  operation  aspects  for  the  ISSS  segment.  As  the  various  AAS  segments  are 
implemented,  this  document  will  be  updated  to  provide  the  reader  with  information 
relative  to  the  changes  from  the  previous  segment  upgrade. 

1.1  PURPOSE. 

The  purpose  of  the  SSCC  Operations  Concept  Docxanent  is  to  provide  a  high  level 
overview  and  a  broad  understanding  of  the  SSCC-1  portion  of  the  AAS.  To  achieve 
this  purpose,  the  document  defines  the  operational  processes  necessairy  to  support 
the  ISSS  segment  of  the  AAS.  This  includes  identification  of  the  users  and  their 
respective  tasks,  and  definition  of  the  procedures  necessary  to  accomplish  those 
tasks .  It  also  identifies  the  diverse  set  of  tools  which  will  be  used  to  provide 
the  necessary  software  development,  testing,  and  maintenance  of  the  AAS. 

1.2  SSCC-1  MISSION. 

The  mission  of  the  SSCC-1  is  to  centralize  the  management,  maintenance,  and  support 
of  the  Air  Route  Traffic  Control  Center's  (ARTCC)  operational  systems.  This 
mission  is  accomplished  by  achieving  the  following  objectives: 

a.  Provide  Configuration  Management  (CM)  of  both  hardware  and  software 

b.  Update  and  store  all  logic  and  Sector  Suite  adaptation  data 

c.  Develop,  test,  and  distribute  system  releases 

d.  Assist  site  software  specialists  in  field  problem  resolution. 


The  nlsslon  statement  was  development  In  accordance  with  the  following  FAA-ER-130- 
005H-AF,  System  Level  Specifications  (SLS); 

a.  SLS  3. 5.4. 5. 3. 2.1.  "The  SSCC-1  will  be  the  focal  point  for  ISSS  software 
maintenance  ...” 

b.  SLS  3. 5. 4. 5. 3.1.  "Software  maintenance  at  the  ISSS  ...  shall  be 
controlled  and  supported  and  configuration  managed  by  the  SSCC  ..." 

c.  SLS  3.7.3.  "Online  storage,  access  and  national  distribution  of  . . .  site 
adaptation  ...  to  operational  sites  ..." 

d.  SLS  3. 5. 4. 4.  "National  Field  Support  Group  (NFSG)  located  at  the  FAATC 
will  act  as  "go  team"  for  field  sites  ..." 

Thus,  the  SSCC-1  is  designed  to  provide  the  following  in  the  fulfillment  of  this 
mission: 


a.  Facilities  and  resources  for  the  development  and  maintenance  of  software 
products 

b.  Diverse  configurations  for  testing,  simulation,  and  research  activities 

c.  An  interactive  Job  Shop  environment  comprised  of  an  integrated  set  of 
Commercial  Off-The-Shelf  (COTS)  products.  Commercially  Available  Software  (CAS), 
and  contract  developed  software 

d.  Networking  services  to  a  geographically  dispersed  user  population. 

1.3  SCOPE. 

This  document  describes  the  SSCC  functional  areas  at  the  process  level  while  it 
defines  the  SSCC-1  objectives.  The  SSCC-1  operations  and  maintenance  support  to 
operational  field  sites  are  discussed  in  detail.  Procedures  and  the  functional 
flows  necessai^  to  provide  centralized  maintenance  support  to  the  ARTCC  are 
identified. 

Section  1  briefly  describes  the  purpose  and  format  of  the  Operations  Concept 
Document  while  providing  the  reader  with  a  cursory  overview  of  the  mission  and 
history  of  the  FAA's  support  maintenance  role. 

Section  2  identifies  the  documentation  that  was  used  as  reference  during  the 
development  of  this  docviment. 

Section  3  provides  the  reader  with  detailed  descriptions  of  the  SSCC  hardware  and 
software  configurations. 

Section  4  describes  the  SSCC  system  operations  and  functions  at  the  process  level 
and  how  those  functions  fit  into  the  centralized  maintenance  concept. 

Section  5  provides  an  insight  to  the  SSCC  method  of  system  maintenance. 

Section  6  defines  the  manpower  resource  requirements  necessary  for  FAA  Technical 
Center  SSCC-1  operations  and  describes  the  varied  management  and  operator 
responsibilities . 
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Section  7  identifies  the  required  training  programs  for  the  various  positions 
required  to  function  with  the  SSCC-1. 

Detailed  procedures  and  step-by-st«‘''  operating  Instructions  are  referenced  in  the 
appendices  and  provided  In  the  IHh  PU  series  Contract  Data  Requirements  Lists 
(CDRLs) . 

1.4  BACKGROUND. 

The  FAA  Technlca’’  Center  in  Atlantic  City,  NJ,  is  chartered  to  provide  system 
development  and  maintenance  support  to  the  field  sites  throughout  the  country  on  a 
24-hour -a- day ,  7-day-a-week  basis.  With  the  advent  of  SSCC-1,  the  entire 
development,  testing,  and  deployment  process  for  supporting  field  sices  will 
undergo  radical  change.  These  modifications  are  briefly  described  In  the  following 
subsections,  while  more  detailed  explanations  are  provided  In  subsequent  chapters. 

Ix.4.1 _ Current  System  Support. 

The  present  means  of  providing  software  maintenance  support  Is  based  on  the  HOST 
Computer  System  (HCS) .  The  HCS  performs  two  primary  system  support  functions  which 
are: 

a.  System  development,  testing,  and  deployment 

b.  Field  support. 

Software  consists  of  two  parts:  logic  and  adaptation  data.  Logic  Is  the  term  used 
to  denote  the  actual  software  coding.  Adaptation  data  consists  of  the  site 
specific  parameters  which  are  unique  to  each  air  traffic  control  (ATC)  facility 
which  are  comprised  of  ARTCCs  and  airport  traffic  control  towers  (ATCT) . 

In  the  current  system,  the  FAA  Technical  Center  provides  system  maintenance  to  the 
ATC  facilities,  but  the  ARTCCs  retain  Jurisdiction  of  the  adaptation  data  and  the 
repair  capability.  The  adaptation  data  for  each  ARTCC  Is  stored  only  at  the 
respective  site. 

Normally,  the  FAA  Technical  Center  does  not  have  Immediate  access  to  a  site's 
adaptation  data,  but  they  do  have  access  to  the  configuration  of  the  site  logic. 

The  F/.\  Technical  Center  can  logically  replicate  the  National  Airspace  System  (NAS) 
and  duplicate  the  logic  of  any  site.  FAA  Technical  Center  adaptation  Is  In  the 
form  of  a  generic  set  of  adaptation  data  called  a  Universal  Data  Set  (UDS) .  By 
using  the  UDS,  the  FAA  Technical  Center  can  perform  field  site  problem  analysis  or 
conduct  tests.  The  UDS  does  not  replicate  any  particular  site;  however,  it  is  the 
basis  for  the  current  methods  of  problem  resolution  and  test  activities. 

Construction  of  the  NAS  operational  system  requires  complete  integration  of  the 
adaptation  data  with  the  logic,  which  results  in  a  System  Build.  Since  each  site 
retains  Its  own  set  of  adaptation  data,  each  site  must  build  its  own  system.  The 
FAA  Technical  Center  does  not  have  that  capability. 

Consequently,  the  FAA  Technical  Center  does  not  have  the  capacity  to  conduct 
exhaustive  system  release  testing,  and  each  ARTCC  Is  responsible  for  testing 
national  logic  with  their  site  adaptation  data. 
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The  majority  of  the  present  application  software  logic  is  contractor-developed. 

The  architecture  of  the  software  loads  the  application  code  into  specific  memory 
locations  which  provides  the  capability  to  correct  a  logic  problem  by  "patching." 
Patching  allows  a  site  only  limited  ability  to  modify  the  software  which  results  in 
the  software  logic  varying  from  site  to  site.  This  process  requires  extensive  CM 
and  complicates  problem  analysis. 

1-^-2 _ SSCC-1  System  Support. 

The  Technical  Center  will  be  the  support  hub  of  management,  maintenance,  and 
testing  of  AAS  software  and  hardware  configurations  for  all  AAS-equipped  ATC 
facilities  on  a  24-hour-a-day ,  7-day-a-week  basis.  The  following  Technical 
Center  organizations  play  major  roles  in  supporting  the  SSCC's  mission: 

a.  ACN-300,  Advanced  Automation  Systems  Division.  Provides  continued  support 
In  the  testing  of  new  developments  and  requirements  to  be  implemented  in  the  AAS  as 
approved  system  modifications. 

b.  ACN-400,  NAS  Facilities  Software  Engineering  Division.  Provides  software 
development.  Center  systems  maintenance,  enhancement  for  aircraft  target  simulation 
systems,  NAS  operational  support  systems,  and  engineering  computer  systems. 

c.  ACN-500,  NAS  Facilities  Hardware  Engineering  Division.  Plans,  manages, 
directs,  and  coordinates  the  technical,  electronic,  electrical,  and  digital 
engineering  for  the  Technical  Center  laboratories  and  facilities.  Also  provided 
are  the  technical  utilization,  maintenance,  modifications,  and  Installation  of 
diversified  electronic  systems  and  facilities. 

d.  ACN-600,  NAS  Facilities  Operations  Division.  Provides  for  operation  of 
the  service's  Automated  Data  Processing  (ADP)  laboratories,  supporting  facilities, 
and  services  at  the  Technical  Center  required  by  all  Center  organizations ,  AXD , 
contractors,  and  field  support  elements.  Alsu  performed  are  system  management 
functions  ensuring  efficient  use  of  equipment  to  meet  the  user-community 
requirements . 

e.  AOS -300/400,  Operational  Support  Services.  Provides  problem  resolution 
support  and  software  maintenance  services  to  the  field  sites. 

As  the  Technical  Center  takes  on  a  new  role  as  the  hub  for  centralized  maintenance, 
the  SSCC-1  will  become  the  central  repository  for  source  logic  and  Sector  Suite 
Adaptation  Data  for  20  ARTCCs.  The  SSCC-1  will  be  available  for  scheduled  use  by 
all  organizations  conducting  testing  for  NAS  programs. 

It  is  envisioned  that  the  National  Automation  Engineering  and  Field  Support 
Division  (AOS)  organization  will  have  the  requisite  skills  and  resources  to  fulfill 
maintenance  responsibilities  after  the  expiration  of  International  Business 
Machine's  (IBM)  maintenance  contract.  IBM  will  provide  maintenance  support  at  the 
sites  for  the  first  year  on  a  24-hour-a-day  basis.  Table  1.4. 2-1  contrasts  the 
changes  in  support  capabilities  that  will  be  introduced  with  the  implementation  of 
the  SSCC-1. 
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TABLE  1.4. 2-1. 


SYSTEM  SUPPORT  CAPABILITIES  COMPARISON 


SUPPORT 

CAPABILITY 

CURRENT  SYSTEM 

SSCC-1  SYSTEM 

Adaptation  Data  Storage 

Resident  at  ARTCC 

Centrally  located  at 

FAA  Technical  Center 

Site  Software  Fixes 

Permitted  at  ARTCC 

Prohibited  at  ARTCC 

System  Builds 

Adaptation  data 
intertwined 
w/software  logic 
compilations 

Software  logic 
compilations 
independent  of 
adaptation  data 

Software  Logic 
Maintenance 

Customized  software 
maintained  by  ARTCC 

All  logic  maintained  at 

FAA  Technical  Center 
Extensive  use  of  CAS 

Transmission  of 

Software 

Tape  distribution 

Added  Capability: 

Electronic  transmission 

Site  Hardware 
Configuration 

Configure  on  HCS 

Configure  two  ISSSs 
s imul taneous ly 

Site  Simulation 

Limited  capability  at 
FAA  Technical  Center 

Logically  replicate  any 
ISSS 

ARTCC  Remote  Logon 
to  Job  Shop 

Available  but  very 
limited  functionality 

New  Capability:  Permitted 
but  controlled 

In  AAS,  there  is  still  a  unique  and  important  role  that  cannot  be  performed  by 
Technical  Center  personnel,  and  this  is  the  maintenance  of  the  local  site 
adaptation  data.  The  sites  remain  the  experts  and  sole  authority  over  their  local 
adaptation  data.  They  own  the  data,  they  are  qualified  in  its  use  and 
understanding,  and  they  are  solely  responsible  for  its  continued  maintenance  and 
updating.  The  fact  that  the  databases  physically  reside  at  the  SSCC  and  do  not 
reside  at  the  sites  in  no  way  diminishes  or  limits  field  site  responsibility  for 
their  maintenance.  The  ACN  and  AOS  organizations  will  continuously  work  together 
in  the  support  of  the  field  sites  to  maintain  an  efficient  system. 
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The  field  site  personnel  have  the  capability  to  schedule  the  SSCC  to  test  and 
maintain  local  adaptation  data.  Field  sites  are  provided  with  remote  access  to 
SSCC  resources.  This  remote  SSCC  access  is  used  for  problem  reporting,  adaptation 
data  maintenance,  hardware  symptom/fix  database  inquiries,  generation  of 
appropriate  site  software  products,  and  other  related  maintenance  activities. 

Field  sites  will  not  have  a  slte>resident  software  development  environment  and 
toolset  to  perfomm  software  development.  Software  maintenance  will  be  performed  by 
a  site  specialist  by  accessing  the  SSCC-resident  databases  and  toolsets.  A  limited 
software  modification  capability  will  be  site -resident,  to  be  used  in  concert  witli 
the  SSCC  to  address  emergency  corrections  to  ATC  software  logic. 

The  centralized  software  maintenance  concept  requires  field  site  personnel  to  work 
in  close  partnership  with  AOS  personnel  to  perform  national  adaptation  data 
updates ,  and  solve  operational  hardware  and  software  problems .  AOS  personnel 
maintains  the  baseline  and  support  software,  and  the  national  adaptation  databases. 
AOS  will  be  available  24  hours  a  day,  7  days  a  week  to  resolve  field  site  problems. 
AOS  will  be  responsible  for  updating  national  adaptation  data  for  all  ARTCCs . 

Also,  AOS  is  responsible  for  providing  weekly  adaptation  updates  to  field  sites. 

The  SSCC-1  will  be  able  to  logically  replicate  the  ISSS  configuration  of  any  site. 
There  will  be  two  System  Support  Facilities  (SSF) ,  ISSS-1  and  ISSS-2.  The  primary 
use  of  the  SSFs  is  to  replicate  ISSS  field  sites  in  order  to  update,  test,  and 
modify  source  software  logic  and  sector  suite  adaptation  data  changes.  ISSS-1 
and  ISSS-2  resources  will  be  available  for  schedule  use  by  all  organizations  who 
conduct  testing  for  the  NAS,  which  includes  ARTCC  personnel.  The  ISSS-1  and 
ISSS-2  will  be  maintained  by  ACN-400,  scheduled  as  a  resource  by  ACN-600.  A 
new  organization  will  be  established  for  CM  in  the  Engineering,  Test  and  Evaluation 
Service  (ACN) . 

The  SSFs  will  enable  the  AOS  personnel  to  replicate  field  site  problems  and  aid  in 
problem  resolution  and  site-specific  testing.  Problems  found  and  reported  by  the 
site-resident  software  specialist  are  communicated  to  the  Technical  Center  for 
resolution.  This  is  done  Informally  via  verbal  communications,  and  formally 
through  the  creation  of  a  problem  AAS  Change  Instrument  (ACI).  Data  is  gathered  by 
the  site  specialists  to  assist  the  AOS  organization  with  problem  resolution. 

Through  the  cooperative  efforts  of  the  site  and  AOS  personnel,  a  proposed 
resolution  is  Identified. 

As  required,  a  temporary  fix  or  procedural  work  around  is  developed  for  the 
immediate  use  of  the  site.  If  the  resolution  requires  modification  to  operational 
ATC  software,  a  logic  release  is  created,  introducing  the  fix  as  a  source  change  at 
the  SSCC.  The  modified  source  is  then  compiled  and  processed  to  produce  an  output 
product.  Following  the  necessary  binding  and  linking,  a  resultant  load  module  is 
generated.  Tests  are  run  on  the  SSFs  to  verify  the  correctness  of  the  source - 
based  fix.  Upon  successful  completion  of  SSCC  testing,  the  logic  release  is 
packaged  into  a  system  release  for  site  installation  and  is  then  made  available  for 
deployment  (electronic  deployment  for  small  corrections  and  updates) .  Testing  and 
certification  must  be  performed  at  the  site,  before  the  new  system  release  is  made 
available  for  operational  use  via  the  applicable  cutover  procedures . 

A  significant  portion  of  the  new  software  logic  will  be  based  on  CAS.  The 
Technical  Center  will  be  a  central  location  to  coordinate  with  the  corresponding 
software  vendors  for  corrections  and  updates. 
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The  SSCC  will  be  able  to  support  the  field  sites  when: 


a.  Software  problems  occur 

b.  Hardware  problems  occur 

c.  Firmware  problems  occur 

d.  Site  specific  adaptation  needs  to  be  modified 

e.  System  releases  are  deployed 

f.  During  normal  operations,  on  an  interactive,  as  needed  basis 

By  the  first  ISSS  Readiness  Demonstration  (ORD) ,  which  is  in  Seattle,  the  SSCC  will 
be  able  to  support  software  functions,  hardware  functions,  firmware,  CM,  and 
maintenance  functions.  These  represent  the  minimum  functional  requirements 
necessary  to  support  a  fielded  ISSS.  The  SSCC  will  at  that  time  consist  of  two 
ISSS  support  facilities  with  Common  Consoles  (CCs)  populated  with  Eagle  processors. 
The  HOST  processors,  Stand-Alone  Simulators  (SAS) ,  and  Peripheral  Adapter  Module 
Replacement  Items  (PAMRI)  are  shared  by  the  two  ISSSs.  In  addition,  the  AAS  Job 
Shop  will  have  been  validated  and  available  to  perform  SSCC  support  functions. 


2.  REFERENCE  DOCUMENTATION. 


The  following  documentation  was  used  as  reference  information  during  the 
development  of  the  SSCC-1  Operations  Concept  Document. 

2.1  FAA  DOCUMENTATION. 

AAS  Integrated  Logistics  Support  Plan,  Draft,  08/15/91 

AAS  SSCC-l/ISSS  Operational  Concepts  Information,  SSCC-1  SMT  Operations  Working 
Group  Working  Paper,  02/21/91 

Air  Traffic  Software  Support  Requirements  Team,  Initial  Sector  Suite  System,  Site 
Software  Support  Operations  Concept,  Version  1,  10/01/92 

AOS  Configuration  Management  Functions,  Draft,  12/12/91 

Concept  of  Operations  for  Utilization  of  the  DDF  As  A  Support  Software  Mimic  Suite 
vSSMS),  Version  1.2,  01/14/92 

Maintenance  Requirements  for  ISSS,  TAAS,  ACCC  Segments  of  the  AAS,  01/23/92 
NAt>  EnRoute  System  Support  Facility  Laboratory  Handbook,  04/91,  NASP-5204-05 
NAS  Terminal  System  Support  Facility,  Laboratory  Handbook,  06/90 
2 ■ 2  CONTRACTOR  DOCUMENTATION . 

IBM,  CDRL  A093,  SSCC  System  Segment  Specification  10/15/90,  FAA-AP-TBD 

IBM,  CDRL  A117Z,  FAA  Advanced  Automation  System,  Software  Requirements 
Specification,  Commercially  Available  Software  (CAS),  dated  10/15/90, 

FAA-AP- 1990-4305 
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IBM,  CDRL  EN09,  Controller  Interaction  and  Task  Analysis,  Volume  1,  Fart  II, 
08/31/92,  FAA-AP-TBD 

IBM,  CDRL  EN09,  Controller  Interaction  and  Task  Analysis,  Volume  1,  Part  III, 
08/31/92,  FAA-AP-TBD 

IBM,  CDRL  PUOl,  System  Maintenance  and  Support  Manual,  SSCC  Job  Shop/Facility  and 
Simulation  Control  Subsystems,  FAA-AP-TBD 

IBM,  CDRL  FU02,  FAATC  Job  Shop/F&SC  Computer  Operations  Manual,  Volume  1,  11/25/91, 
FAA-AP- 1990 -3814 

IBM,  CDRL  FU09,  ISSS  FAATC  Software  Maintenance  Manual  (Job  Shop  Functions), 

Volume  1,  06/10/92,  FAA-TBD 

IBM,  CDRL  PU09,  ISSS  FAATC  Software  Maintenance  Manual,  (Job  Shop  Tools),  Volume  3, 
11/02/92,  FAA-AP- 1992 -2548 

IBM,  CDRL  PU09,  ISSS  FAATC  Software  Maintenance  Manual,  (Ada  Maintenance  Using 
Rational  RIOOO  Processor),  Volume  4,  11/02/92,  FAA-AP- 1992 -2549 

IBM,  CDRL  PU09,  ISSS  FAATC  Software  Maintenance  Manual,  (RISC  System/6000), 

Volume  5,  11/02/92,  FAA-AP- 1992 -2545 

IBM,  CDRL  PU09,  FAA  Advanced  Automation  System  (AAS),  ISSS  FAATC  Software 
Maintenance  Manual,  Volume  2,  Job  Shop  Configuration  Control  and  Management, 
06/11/92,  FAA-AP- 1992 -TBD 

IBM,  CDRL  PUll,  AAS  Change  Instrument  (ACI)  Users  Manual,  Informal  Draft,  01/10/92, 
FAA-AP- 1992 -TBD 

IBM,  CDRL  pull,  FAA  AAS  Acquisition  Phase,  Adaptation  Data  Manual,  Volume  1, 
Overview,  04/29/92,  FAA-AP- 1992 -TBD 

IBM,  CDRL  PUll,  Document  Maintenance  Manual,  05/13/92,  FAA-AP-1991-1634 

IBM,  CDRL  PU12,  ISSS  Advanced  Automation  System,  Overview  Manual,  First  Draft, 
11/02/92,  FAA-AP-1992-TBD 

IBM,  CDRL  TE24,  Software  Test  Procedures  Volume  1,  Book  510.17,  Final,  FAA-AP-TBD 

IBM,  CDRL  TR08,  FAA  Advanced  Automation  System  (AAS),  Test  and  Evaluation  (T&E) , 

FAA  Technical  Center  Training  Analysis  Report,  Section  1,  07/92,  FAA-AP- 1992 -TBD 

IBM,  CDRL  TR08,  FAA  Advanced  Automation  System  (AAS,  Test  and  Evaluation  (T&E), 

FAA  Technical  Center  Training  Analysis  Report,  Section  2,  11/92,  FAA-AP- 1992 -TBD 

IBM,  SSCC-1  Operations  Working  Group,  FAATC  Personnel  Required  To  Support  The  SSCC 
Job  Shop,  12/12/90 

IBM,  System  Support  Computer  Complex  (SSCC-1)  Operations  Concept,  Draft,  12/07/89 
IBM  (Internal  Document)  Logic  Flow,  03/29/92 
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The  SSCC  contains  sufficient  hardware,  software,  and  Interface  resources  to 
logically  replicate  the  complete  hardware  and  software  configuration  of  any 
operational  field  site  equipped  with  the  AAS.  The  SSCC  assists  AOS  personnel 
In  replicating  field  site  problems  and  resolving  them.  The  SSCC  also  provides  an 
environment  for  software  development  and  testing,  and  for  creating  and  deploying 
new  system  releases  to  the  sites.  By  design,  a  significant  portion  of  the  new 
software  logic  Is  based  on  commercially  available  software. 

The  SSCC  will  evolve  Incrementally.  In  the  end  state,  the  SSCC  will  support  the 
following  functions: 

a.  The  testing.  Implementation,  centralized  maintenance,  modification,  and 
enhancement  of  all  AAS  hardware  and  software. 

b.  The  CM,  qviality  assurance,  performance  assessment  and  adaptation  data 
management,  and  static  data  management  of  all  FAA  sites  which  operationally 
Implement  AAS  hardware  and  software. 

c.  The  on-line  storage,  access  and  national  distribution  of  bulk  store  flight 
plans,  AAS  documentation,  site  adaptation  data,  static  data,  and  AAS  software 
configuration  items,  to  operational  sites. 

d.  The  development  of  system  modifications,  enhancements,  upgrades,  and 
extensions . 

The  SSCC  also  provides  functionality  for  management  of  Its  resources  to: 

a.  Control,  partition,  allocate,  and  validate  Its  own  resources. 

b.  Assist  FAA  management  In  planning  and  scheduling  the  allocation  of  SSCC 
resources . 

c.  Provide  performance  monitoring  of  Itself. 

The  SSCC-1,  which  supports  the  ISSS,  consists  of  three  major  subsystems: 

a.  AAS  Job  Shop 

b.  Facility  and  Simulation  Control 

c.  ISSS  System  Support  Facilities 

Figure  3-1  Illustrates  the  major  functions  performed  at  the  SSCC  and  the 
relationship  between  the  Job  Shop  and  the  ISSS  sites.  Each  of  the  SSCC-1 
subsystems  Is  explained  In  this  section.  The  details  pertaining  to  SSCC-2, 

SSCC- 3,  and  SSCC-4  will  be  included  in  future  revisions  of  this  document. 

3.1  AAS  JOB  SHOP  ARCHITECTURE. 

The  AAS  Job  Shop  provides  users  with  tools  for  software  development  and 
maintenance,  test  and  verification,  technical  management,  configuration  management, 
and  field  support  functions.  It  also  provides  access  to  users  at  operational  field 
sites  for  adaptation  data  collection,  problem  reporting,  and  system  distribution. 
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FIGURE  3-1.  SSCC  JOB  SHOP  FUNCTIONS  AND  ISSS  SITE  RELATIONSHIPS 


The  hardware  configuration  at  the  Job  Shop  is  shown  in  figure  3. 1.1-1.  Table 
3. 1.1-1  lists  the  hardware  subsystem  which  comprise  the  Job  Shop. 


TABLE  3. 1.1-1.  AAS  JOB  SHOP  HARDWARE  DESCRIPTION 


SUBSYSTEM 

DESCRIPTION 

IBM  3090  Model  600E  Central 
Processor  Complex 

Central  Processor  Complex  that  supports  the 
development,  maintenance,  enhancement,  and 
continuous  operation  of  the  AAS  facilities. 

It  provides  automated  compilation  and  build 
control,  and  centralized  CM  for  all  developed 
software . 

Communication  Controller 

Provides  logon  access  to  field  sites  for 
adaptation  data  collection,  problem  reporting, 
and  system  distribution. 

Network  Compilation  Facility 
(NCF) 

Provides  the  compilation  environment  to 
compile  RISC  System/6000  targeted  Ada  code. 

Rational  Computer  System 

Provides  Ada  support  for  developing  software 
through  functional  unit  test. 

Intelligent  Workstations  (IWS) 

Provides  for  unit  testing  Ada  code. 

Direct  Access  Storage  Devices 
(DASDs) 

Numerous  large  capacity  storage  devices  that 
connect  to  the  processor  through  a  storage 
controller. 

Tape  Devices 

Storage  devices.  Each  tape  storage  unit 
consists  of  two  tape  drives  and  connects  to 
the  processor  through  a  tape  controller. 

Display  Terminals 

Devices  that  are  capable  of  sending  and 
receiving  Information.  Terminals  are  used 
by  the  document  maintainer  to  log  on  to  AAS 
and  view  or  modify  the  documents. 

Printers 

Output  devices  for  maintalners  and  software 
support . 
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3090  Model  60(£  Processor 


FIGURE  3. 1.1-1.  HARDWARE  CONFIGURATION  OF  THE  AAS  JOB  SHOP 
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The  IBM  3090  Model  600E  processor  complex  consists  of: 


a.  One  IBM  3090-600E  Processor  Unit  with  the  Processor  Resource/Systems 
Manager  (PR/SM)  feature 

b.  One  IWl  3092-005  Processor  Controller 

c.  Two  3097-001  Power  and  Coolant  Distribution  Units 

d.  Three  IBM  3206-110  Display  Stations 

e.  Four  IBM  3089-003  Power  Units 

3.1.1. 1 _ Job  Shop  Ada  Development  Environment. 

The  AAS  Job  Shop  Ada  development  environment  configuration,  as  shown  In 
figure  3. 1.1. 1-1,  consists  of  an  IBM  3090-600E  central  processing  complex, 
an  NCF,  and  a  Rational  RIOOO  Series  200  Model  40  Ada  development  system 
connected  via  a  token- ring  Local  Area  Network  (LAN)  to  Common  Tonsole 
Processors  (CCPs)  and  Personal  System  (PS)  Intelligent  Workstations  (lUS) . 

The  NCF  consists  of  two  Reduced  Instruction  Set  Computer  (RISC)  System/6000 
Model  950  machines  to  compile  Ada  code  targeted  for  execution  on  RISC  6000s. 

The  processing,  compiling,  and  binding  are  performed  under  the  control  of 
Software  Configuration  Library  Manager  (SCLM)  numlng  on  the  AAS  Job  Shop 
processor  (3090-600E).  The  Multiple  Virtual  Storage  (MVS)  partition  on  the 
IBM  3090- 600E  Is  the  CM  residence  for  the  source  code  and  the  compiler  outputs. 

The  Rational  RIOOO  Series  200  Model  40  Ada  development  system  consists  of 
specialized  processors,  terminals,  and  software.  The  Rational  RIOOO  system, 
which  does  not  support  the  token  ring.  Is  connected  to  the  token- ring  LAN  via 
a  7018-741  gateway. 

The  IWSs  are  PS/2s  connected  to  the  token-ring  LAM  via  standard  token-ring 
adapters.  One  of  the  PS/2s  from  the  IWS  pool  Is  assigned  as  network  manager. 

The  CCP  workstations  (RISC  System/6000  Model  7018-740)  provide  the  target 
environment  for  unit- testing  Ada  code.  Ada  support  Includes,  at  a  minimum, 
an  Ada  compiler  and  symbolic  debugger.  The  network  supports  a  distributed 
file  system  for  the  CCP  workstations.  The  IWS  and  CCP  workstations  are  capable 
of  serving  as  terminals  to  either  the  central  processing  complex  or  the  Rational 
machines . 
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FIGURE  3. 1.1. 1-1.  ADA  DEVELOPMENT  ENVIRONMENT  CONFIGURATION 
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The  IBM  RISC  Systeiii/6000  system  units  are  a  second  generation  of  computers  using 
the  architecture.  They  offer  a  full  range  of  multiuser,  multitasking,  open- 
architecture  workstations  and  servers.  Four  models  of  the  IBM  RISC  System/6000 
are  used  in  AAS: 

a.  Model  7018-741  is  used  as  interface  units  and  gateways.  Examples  are  the 
Local  Communication  Network  Interface  Units  (LIUs),  Common  Console  Simulators 
(CCSs),  and  Enhanced  Direct  Access  Radar  Channel  (EDARC)  System  Interface  (ESI). 

b.  Model  7018-740  is  used  in  the  CC  as  the  CCP. 

c.  Model  7013-520  is  used  as  workstations  in  the  Job  Shop  for  software 
diagnostics  and  maintenance. 

d.  Model  7015-950  is  used  in  the  Job  Shop's  Network  Compilation  Facility 
(NCF)  to  compile  Ada  programs  targeted  for  RISC  System/6000  processors. 

3. 1.1. 2  AAS  JOB  SHOP  PARTITIONS. 

The  AAS  Job  Shop  3090  system  includes  a  hardware  feature  called  Processor 
Resource/Systems  Manager  (PR/SM) ,  which  is  used  to  partition  the  3090  processors. 
The  maximum  number  of  partitions  that  can  be  simultaneously  active  for  the  IBM  3090 
Model  600E  is  four.  The  AAS  Job  Shop  is  currently  divided  into  the  following  four 
partitions ; 

a.  three  processors  allocated  to  Production 

b.  one  processor  allocated  to  Test 

c.  one  processor  allocated  to  Central  Support 

d.  one  processor  allocated  to  Software  Development 

Table  3. 1.1. 2-1  shows  the  functions  performed  in  each  partition. 
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TABLE  3. 1.1. 2-1. 


AAS  JOB  SHOP  PARTITION  FUNCTIONS 


Production 

MVS/ 

Extended  - 

Architecture 

(XA) 

Software  Development  Environment 

-  Change  Tracking  System 

-  Configuration  Management 

-  Software  Development  Environment  (Ada/370, 
Ada/6000,  CSP,  C/370.  C/6000,  ASM/370) 

-  AAS  Adaptation  Data  Maintenance 

-  Documentation  Maintenance 

-  System  Analysis.  Recorder  (SAR)  -  Data 
Reduction  and  Analysis  (DRAA) 

•  Support  Software  Problem  Determination 

•  Support  Software  Unit,  String,  Integration, 
System  Test 

-  Ada/370  Unit  Testing 

Test 

MVS/XA 

•  MVS  CAS  Product  Administration 

•  MVS  CAS  Product  Regression  Testing 

Central  Support 

Virtual 

-  NAS  Software  Builds 

(CS 

Machine 

-  NAS  Modifications  for  ISSS  (NASM)  Software 
Builds 

(VM)/ 

-  Field  Support 

System 

-  Info  Management 

Product  (SP) 

-  Mall 

-  MVS/SP 

Guest 

-  HOST  DR&A 

Soft  are 

VM/ 

-  NAS  Software  Development 

Development  (SD) 

Extended 

-  NASM  Software  Development 

System 

-  NAS  Software  Test 

Architecture 

(ESA) 

-  NASM  Software  Test 
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A  diverse  set  of  users  has  access  to  the  Job  Shop.  Software  developers  develop  and 
test  software  and  database  updates .  Document  maintalners  modify  and  create 
documentation.  Field  support  personnel  Interrogate  the  system  to  resolve  reported 
problems.  Site  personnel  remotely  access  and  update  adaptation  data  to  keep  the 
data  current  and  accurate .  CM  personnel  maintain  and  control  these  processes  to 
ensure  Integrity. 

The  software  used  to  perform  these  Job  Shop  functions  Is  a  combination  of  CAS 
products.  Computer  Software  Configuration  Items  (CSCIs),  and  tools.  Figure 
3. 1.2-1,  Support  Software  at  the  AAS  Job  Shop,  shows  the  layers  of  support  software 
residing  on  the  IBM  3090  system.  It  also  shows  how  some  of  the  CSCIs  and  CAS 
products  Interrelate.  The  figure  legend  lists  the  CAS  products.  Site  Data 
Collection  (SITE) ,  Environment  Data  Collection  (ENVT)  and  Change  Control  and  Build 
(CCAB)  are  AAS  CSCIs. 

3. 1.2.1  Commercially  Available  Software  (CAS). 

Figures  3. 1.2. 1-1  and  3. 1.2. 1-2  show  the  Commercially  Available  Software  (CAS) 
products  residing  on  the  IBM  3090  system  for  each  operating  system.  The  CAS 
products  can  be  divided  Into  four  groups: 

a.  System  Control  Software  -  Software  used  to  control  the  system  and  allocate 
resources  to  application  programs,  and  software  used  to  monitor  the  performance  of 
the  hardware  and  software. 

b.  System  Confl^ratlon  and  Management  Software  -  Software  supporting  the 
management  of  the  system.  Including  hardware  and  software  CM,  schedule  management, 
and  planning. 

c.  Program  Development  Support  Software  -  Software  supporting  the  development 
and  testing  of  software. 

d.  Cnnnmini cations  SuPDort  Software  -  Software  to  allow  communications  between 
terminals  and  the  processor,  between  processors,  and  between  facilities. 


Tables  3. 1.2. 1-1  through  3. 1.2. 1-4  provides  a  brief  description  of  each  CAS 
product.  Detailed  descriptions  are  located  In  the  FU  series  documents. 
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FIGURE  3. 1.2-1.  SUPPORT  SOFTWARE  AT  THE  AAS  JOB  SHOP 
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SSCC  AAS  Job  Shop  Processor  (MVS  Partitfon) 
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FIGURE  3. 1.2. 1-1. 


IBM  3090  RESIDENT  CAS  PRODUCTS  (MVS  PARTITION) 


19 
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FIGURE  3. 1.2. 1-2. 


IBM  3090  RESIDENT  CAS  PRODUCTS  (VM  PARTITION) 


TABLE  3. 1.2. 1-1. 


SYSTEM  CONTROL  SOFTWARE 


CAS  PRODUCT 

DESCRIPTION 

Conversational  Monitor  System 
(CMS) 

Operates  under  VM/ESA  to  provide  interactive 
access  to  the  various  support  functions. 

Data  Facility /Data  Set  Services 
(DF/DSS) 

Assists  MVS/XA  users  with  protection  and 
recovery  of  information  on  DASD. 

Data  Facility  Hierarchical 

Storage  Manager  (DFHSM) 

Manages  and  co.''trols  various  data  storage 
devices  on  MVS/XA.  Provides  functions  such 
as  automatic  backup  and  recovery  of  data 
sets  conversion  of  data  sets  across 
different  device  types,  and  archiving  of 
less  active  data  sets. 

Data  Facility  Product  (DFP) 

Provides  data  management,  device  support, 
program  library  management,  utility 
functions,  and  system  catalog  support. 

Data  Facility  Sort  (DFSORT) 

A  high  performance  sort  for  blocked  or 
unblocked  sequential  data  sets  containing 
fixed  or  variable  length  records. 

Device  Support  Facilities  (DSF) 

Supports  the  central  processor  attached 

DASD,  and  allows  access  to  data  during 
media  maintenance  processing. 

Data  Extract  (DXT) 

Allows  the  tiser  to  extract  selected 
operational  data  and  formats  data  for 
loading  into  Data  Base  2  Data  Base 

Application  (DB2) . 

Multiple  Virtual  Storage/ 

Extended  Architecture  (MVS/XA) 

The  virtual  storage  operating  system  for 
all  AAS  central  processors. 

Resource  Access  Control  Facility 
(RACF) 

Provides  a  full-function  access  control 
system  for  the  VM/ESA  and  MVS/XA  environ¬ 
ments  . 

Resource  Measurement  Facility 
(RMF) 

Centralized  measurement  tool  that  monitors 
system  activity  to  collect  performance  and 
capacity  planning  data. 

Print  Services  Facility  (PSF) 

Provides  device  and  resource  management 
support  for  the  3820  Page  Printer,  under 
the  MVS  environment. 
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TABLE  3. 1.2. 1-1. 


SYSTEM  CONTROL  SOFTWARE  (Continued) 


CAS  PRODUCT 

DESCRIPTION 

System  Display  and  Search 

Facility  (SDSF) 

A  system  management  aid  that  provides  users 
dynamic  access  to  MVS  system  log  and  Job 

Entry  Subsystem  queues . 

Statistical  Package  for  the 

Social  Sciences  (SPSS-X) 

SPSS-X  a  product  of  SPSS,  Inc.  General 
purpose  statistical  analysis  program 
that  is  used  in  AAS  for  DR6A. 

Time  Sharing  Option/Extensions 
(TSO/E) 

Provides  interactive  users  with  additional 
function,  Improved  usability,  and  improved 
perfoirmance .  Operates  under  MVS/XA  to 
provide  interactive  access  to  the  various 
support  functions. 

VM/ESA  with  High  Performance 
Option  (VM/ESA  w/HPO) 

The  virtual  storage  operating  system  for 
the  HOST  Computer  System  (HCS). 

TABLE  3. 1.2. 1-2.  SYSTEM  CONFIGURATION  AND  MANAGEMENT  SOFTWARE 


CAS  PRODUCT 

DESCRIPTION 

Data  Base  2  (DB2) 

Provides  a  complete,  full-function  data 
base  management  system  used  in  the 
Implementation  of  the  CM  and  adaptation 
management  functions. 

Operations  Planning  and 
Control/Advanced  (OPC/A) 

Provides  a  comprehensive  software 
scheduling  tool  for  the  MVS  environ¬ 
ment.  OPC/A  plans,  controls,  and 
automates  the  batch  production  workload. 

System  Modification 
Program/Extended  (SMP/E) 

The  basic  tool  for  making  software  changes 
(new  function,  corrective,  and  preventive 
service,  and  user  modifications)  on  MVS/XA. 

Tape  Library  Control  System 
(TLCS) 

Provides  an  automated  library  system 
capable  of  controlling  any  number  of 
tapes.  Provides  magnetic- tape  manage¬ 
ment  functions  for  MVS/XA. 
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TABLE  3. 1.2. 1-3.  PROGRAM  DEVELOPMENT  SUPPORT  SOFTWARE 


CAS  PRODUCT 

DESCRIPTION 

Cross  System  Product/Application 
Development  (CSP/AD) 

Provides  complete  facilities  for  programmers 
to  define  and  generate  applications. 

CSP/Appllcatlon  Execution 
(CSP/AE) 

Executes  the  generated  programs  in  a 
production  environment. 

Interactive  System  Productivity 
Facility  (ISPF) 

Provides  dialogue -laanagement  services  in 
the  MVS/XA  TSO  and  VM/CMS  environments. 

These  services  provide  the  Computer  Human 
Interface  (CHI)  for  all  AAS  support 
functions  in  the  form  of  menu-based 
dialogues  that  sisiplify  using  the 
application. 

ISPF/Program  Development  Facility 
(ISPF/PDF) 

An  interactive  application  that  provides 
common  application  development  services 
to  both  MVS  and  VM  \isers.  Provides  an 
editor  to  create  and  siaintain  both 
source  programs  and  text  data. 

Softwar'!  Configure  and  Library/ 
Manager  (SCLM) 

Part  of  ISPF/PDF.  SCLM  provides  CM  and 
build  support  for  all  AAS  developed 
software . 
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TABLE  3. 1.2. 1-4.  COMMUNICATIONS  SUPPORT  SOFTWARE 


CAS  PRODUCT 

DESCRIPTION 

ACF/System  Support  Programs 
(ACF/SSP) 

A  core  requisite  product  providing  a  set  of 
utility  programs  supporting  the  Advanced 
ComBunication  Facility  (ACF) . 

ACF/Virtual  Telecommunications 
Access  Method  (VTAM) 

Provides  network  management  functions. 

VTAM  supports  concurrent  execution  of 
multiple  telecommunications  applications 
and  controls  sharing  of  resources  among 
applications . 

File  Transfer  Program  (FTP) 

General  purpose  program  used  to  transfer 
files  of  all  sizes  between  facilities, 
such  as  during  the  deployment  of  software 
and  adaptation  data. 

Netview 

Provides  an  enhanced  set  of  network  manage¬ 
ment  functions. 

Virtual  Machine  Pass thru  (PVM) 

PVM  allows  VM/ESA  users  to  interactively 
access  applications  in  another  system.  PVM 
provides  field  site  users  with  the  ability 
to  log  on  via  3270  devices  to  HCS  support 
applications  residing  at  the  SSCC  AAS 

Job  Shop. 

Remote  Spooling  Communication 
System  (RSCS) 

Supports  the  HCS  component  of  ISSS.  It 
provides  file  transfers  between  the  HCS 
support  element  of  the  Job  Shop  and 

Host/ISSS  field  sites. 

Transmission  Control 
Protocol/Intemet  Protocol 
(TCP/IP) 

Provides  the  AAS  Job  Shop  user  with  the 
capability  of  accessing  the  AAS  Job  Shop 

Ada  Development  LAN. 

3 ■ 1 . 2 . 2  Developed  Software . 

The  Job  Shop  contains  six  CSCIs  for  SSCC-1.  These  are  CCAB,  ENVT,  SITE,  Recording, 
Analysis  and  Playback  (RAAP) ,  Man-Machine  Interface  (MMI)  Training  Support  Software 
(MTSS) ,  and  NAS  Modifications  for  ISSS  (NASM) .  Although  each  CSCI  has  specific 
functions,  the  CSCI  being  used  at  any  given  time  is  transparent  to  the  user.  Table 
3. 1.2. 2-1  shows  the  operating  system  relative  to  each  CSCI. 
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TABLE  3. 1.2. 2-1.  SSCC-1  AAS  JOB  SHOP  CSCls 


OPERATING  SYSTEM 

CSCIS 

MVS/XA 

CCAB,  SITE,  ENVT, 

RAAP,  and  MTSS 

vm/esa 

NASM 

The  CCAB  provides  the  Job  Shop's  CM  tools  for  planning,  controlling,  and  tracking 
changes  to  AAS.  It  maintains  Inventories  of  software  components,  hardware 
configurations,  documentation,  and  SSCC  resource  schedules.  The  CCAB's  database 
also  supports  Job  Shop  test  functions  by  providing  test  scheduling  and  tracking 
capability,  test  requirements  review  capability,  and  site  hardware  and  software 
inventory  identification  for  site  specific  testing. 

The  ENVT  supports  the  collection  and  maintenance  of  adaptation  data  as  defined  by 
the  AAS  software. 

The  SITE  provides  the  tools  needed  to  select  data  and  translate  it  for  vise  with  a 
specific  AAS  logic  release. 

The  SITE  also  prepares  the  logic  and  data  for  deployment. 

The  RAAF  provides  the  central  source  of  control  to  support  the  recording  and 
playback  of  display  data,  and  provides  a  central  source  of  control  to  support  the 
recording  and  analysis  of  ISSS  unique  nondisplay  data. 

The  HOST  and  EDARC  nondisplay  recording  and  analysis  are  provided  by  Govemnment 
Furnished  Information  (GFI)  software. 

The  HTSS  provides  the  CC  with  a  Detached  Console  Training  (DCT)  capability  for 
training  purposes. 

The  NASH  provides  the  necessary  modification  of  NAS  software  to  support  ISSS 
requirements.  NAS  software  existing  prior  to  the  ISSS  implementation  is  provided 
as  Government  Furnished  Property  (GFF) .  This  GFP  NAS  software,  called  the  HCS 
software,  consists  of  operational  software,  nonoperational  software,  and 
maintenance  software. 

3 . 2  FACILITY  AND  SIMULATICgT  CQNTRQl^  (F&SC)  ARCHITECTURE . 

The  Facility  and  Simulation  Control  (F&SC)  subsystem  controls  the  assignment  of 
common  resources  between  the  SSFs  and  configures  an  SSF  to  emulate  a  site.  The 
F&SC  consists  of  a  S/390  Model  9121-320  central  processor,  two  Facility 
Configuration  Consoles  (FCC)  for  SSCC-1,  two  SASs,  CCs,  CCCs ,  Test  Interface  Units 
(TIUs) ,  LANs,  and  LAN  LIUs.  The  CCs  and  CCSs  are  a  shared  resource-pool  that  can 
be  configured  to  emulate  any  ISSS  operational  configuration.  The  shared  resources 
are  accessed  through  the  TIUs,  the  Local  Communications  Network  (LCN) ,  and  the 
Backup  Communications  Network  (BCN)  by  means  of  the  FCC.  Figure  3.2-1  is  a 
overview  diagram  of  the  F&SC  subsystem. 
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The  following  CSCls  support  the  F&SC: 

a.  CoBuon  System  Services  (CXSS) 

b.  Recording  Analysis  and  Playback  (RAAP) 

c.  Display  Management  (DISP) 

3.2.1  _ Facility  Configuration  Console  (FCC) . 

The  general  mission  of  the  FCC  position  In  the  SSCC-1  Is  to  assist  FAA  Management 
In  the  configuration,  monitoring,  and  management  of  SSCC-1  resources  that  are 
required  by  ISSS  SSF  users  to  perform  system  testing  and  verification  activities. 
The  FCC  acts  as  a  centralized  position  to  coordinate  the  Interfaces  to  the 
applicable  SSCC-resldent  hardware  subsystems,  and  to  the  operations  personnel  that 
support  these  stibsystems  on  a  continuous  basis. 

During  SSCC-1,  there  are  two  CCs  permanently  assigned  as  FCCs.  One  CC  will 
function  as  the  FCC  for  each  of  the  two  specific  ISSS  SSFs.  The  two  FCCs  work 
Independently  of  one  another.  In  subsequent  segments,  a  single  CC  at  the  FCC 
position  will  serve  both  SSFs. 

3. 2. 1.1  _ Hflr4wftrg • 

The  FCC  position  Is  pictured  In  figure  3. 2. 1.1-1.  The  two  CCs  that  make  up  the 
FCC  position  suites  are  referred  to  as  FCC-1  and  FCC-2.  FCC-1  Is  responsible  for 
the  LCM  network  that  Is  dedicated  to,  and  serves  the  simulation  testing  needs  of 
SSF-1,  and  FCC-2  Is  responsible  for  the  LCN  network  that  Is  dedicated  to,  and 
serves  the  simulation  testing  needs  of  SSF-2. 

In  addition  to  Its  LCN  network  connections,  the  FCC  position  consoles  are  also 
connected  to  the  BCN.  Each  FCC  console  contains  an  adapter  to  connect  to  Its 
respective  BCN,  with  FCC-1  connected  to  BCN-1  and  FCC-2  connected  to  BCN-2.  In 
turn,  BCN-1  or  BCN-2  can  be  switched  to  the  EDARC  subsystem  when  configuring  an  SSF 
for  testing. 

The  FCC  position  suite  also  contains  two  additional  pieces  of  hardware.  The  first 
Is  two  hard  copy  printers,  one  dedicated  to  each  of  the  two  FCC  CCs.  They  are  used 
for  hard  copy  outputs  that  are  requested  by  the  FCC  console  operators.  The  second 
piece  of  hardware  Is  an  Interactive  terminal  or  workstation  that  Is  connected  via  a 
Job  Shop  control  unit  to  the  AAS  Job  Shop  processor  and  Is  shared  by  the  FCC 
console  operators.  This  termlnal/workstatlon  allows  an  FCC  operator  to  logon  to 
the  Job  Shop,  and  to  access  and  Input  Infoinnatlon  relevant  to  the  testing  plans  and 
configuration  requirements  of  scheduled  SSF  users. 

3. 2. 1.2  Software. 

The  FCC  utilizes  the  same  Network  Manager  software  as  the  Monitor  &  Control  (M&C) 
position  of  the  operational  ISSS  SSFs. 
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FIGURE  3. 2. 1.1-1. 
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The  SAS  function  provides  simulation  services  and  test  scenario  generation  for  the 
SSFs.  The  purpose  of  the  SAS  Is  to  support  system  testing  and  verification.  It 
can  provide  continuous  Inputs  for  maximum  stress  and  overload  testing.  It  also 
provides  for  the  execution  and  recording  of  existing  HOST  simulation  capabilities 
(NASH)  3  well  as  the  scenario  generation  and  execution  of  the  simulation 
requirements  of  AAS. 

Stand-alone  simulation  is  performed  using  the  F&SC  9121  processor  with  Adapter 
Units  (AUs)  dedicated  both  physically  and  logically  to  the  SASs.  Each  SAS  AU  set 
Is  comprised  of  two  AU  rack  assemblies.  Each  set  has  the  AU  adapter  cards 
necessary  to  provide  the  associated  ISSS  SSF  35  Interfacility  Input  and  output  line 
pairs  and  75  radar  lines,  which  are  the  maximum  stress  Inputs  and  outputs  for  ISSS. 

The  F&SC  9121  will  have  two  partitions:  one  for  MVS,  the  other  for  Virtual 
Machine/Extended  System  Architecture  (VM/ESA) .  Under  the  VM/ESA  partition,  two 
copies  of  NAS  Looped  Sim  Driver  (SDR)  could  be  executing  simultaneously.  The  SDR 
is  the  software  environment  for  the  SAS,  which  will  operate  in  native  or  VM  mode  on 
the  9121  platform. 

3.2.3 _ Peripheral  Adapter  Module  Replacement  Item  (PAMRI) . 

The  PAMRI  Is  an  upgraded  peripheral  adapter  for  the  AAS.  It  receives  Incoming 
signals  from  radar  or  LAN  lines  and  Is  interfaced  with  the  HOST  computer  system. 

Its  purpose  Is  to  replace  existing  radar  and  communications  Interface  equipment 
with  newly  designed  equipment  having  greater  capacity  and  Improved  supportabllity. 

The  PAMRI  system  consists  of  the  following  four  major  hardware  components: 

a.  Adapter  Units  (AU) 

b.  Radar  Data  Distribution  Units  (RDDU) 

c.  Modem  Splitters  (MS) 

d.  Maintenance  Consoles  (MCs) 

The  PAMRI  subsystem  also  contains  four  PS/2  Model  55SX  computers  which  are  used  as 
maintenance  consoles. 


Data  coming  from  Interfacility  and  external  communications  equipment  are  sent  to 
the  PAMRI  adapter  units  via  the  modem  splitters.  The  MS  direct  the  appropriate 
data  to  their  respective  output  lines  and  transmit  them  to  their  next  destination. 
The  AUs  process  both  the  radar  and  nonradar  data  received  from  the  modem  splitters. 
Radar  data  only  Is  routed  to  the  RDDUs  to  distribute  to  other  radar  subsystems 
attached  to  the  RDDUs  that  require  radar  data. 
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The  SSF  Is  a  collection  of  hardware  resources  used  to  replicate  a  field  site 
configuration.  There  are  two  ISSS  SSFs  in  SSCC-1,  both  of  which  are  managed  by  an 
FCC  position  and  are  similar  in  configuration.  These  two  separate  physical  token 
ring  networks  contain  all  the  resources  and  processing  hardware  to  logically 
replicate  an  ISSS  site.  The  network  composition  of  the  two  SSFs  is  summarized 
below: 


a.  A  set  of  four  separate  token  rings  that  interface  with  FCC-1  and  FCC-2  to 
which  the  TlUs  are  ccunected,  and  to  which  LIUs  are  connected  for  the  three  F&SC 
S/370  processors  that  support  simulation. 

b.  Four  bridges  on  each  o^  two  of  these  four  separate  rings;  these  are 
required  for  interconnection  to  the  two  sets  of  SSF  backbone  rings. 

c.  Two  central  cluster  access  ring  sets. 

d.  The  bridges  required  for  interconnection  of  backbone  ring  sets  1  and  2  to 
the  two  sets  of  central  cluster  access  rings. 

e.  Six  CC  access  ring  sets  (access  ring  sets  1,  2,  and  3  are  dedicated  for 
SSF*1,  and  access  ring  sets  4,  5,  and  6  are  dedicated  for  SSF-2). 

f.  The  bridges  required  for  Interconnection  of  backbone  ring  sets  1  and  2  to 
the  six  sets  of  CC  access  rings. 

Within  each  of  the  processors  of  the  two  CCs  for  FCC-1  and  FCC -2  resides  the  LCN 
Network  Manager  software  function  that  is  responsible  for  managing  the  SSF  token 
ring  networks.  The  FCC-1  copy  of  the  network  manager  software  handles  the  SSF-1 
network  and  its  other  attached  components  (e.g.,  LIUs  and  TIUs),  and  the  FCC-2  copy 
of  the  network  manager  software  handles  the  SSF-2  network  and  its  other  attached 
components . 

To  be  able  to  create  and  control  its  respective  SSF  network,  each  FCC  network 
manager  must  own  the  bridges  (four  of  them)  that  connect  to  the  applicable  SSF 
backbone  ring  let  (one  set  dedicated  for  SSF-1  and  the  other  dedicated  to  SSF-2). 
Each  network  manager  must  also  be  capable  of  issuing  commands  to  Lhes.^  Li.Id^es  to 
accomplish  its  network  management  responsibilities. 

3.3.1  Monitor  and  Control  (M&C)  Cluster  . 

The  Monitor  and  Control  (M&C)  is  a  collection  of  the  following  positions: 

a.  M&C  position.  Consists  of  four  CCs,  connected  to  the  LCN  and  to  the  BCN. 
The  M&C  position  provides  the  capability  to  monitor  ISSS  status  and  control  the 
ISSS  configuration. 

b.  Diagnostic  and  Repair  (D&R)  position.  Consists  of  two  CCs  with  the  same 
connectivity  and  hardware  functionality  as  the  M&C  position. 

c.  Display  Recording  and  Playback  (DR&P)  position.  Consists  of  four  CCs  and 
has  the  same  connectivity  and  hardware  functionality  as  the  M&C  position. 
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The  System  Engineer  has  access  to  all  M6iC  views  while  the  DW  and  DR&P  positions 
have  access  to  subsets  of  M&C  position  views  and  coimands. 

3.3.2  HOST  Computer  System  fHCS) . 

The  HCS  Is  furnished  by  the  FAA  and  consists  of  an  IBM  Model  3083  central 
processor,  a  Model  3082  processor  controller.  Model  3087  cooling  unit,  and  a 
Model  3089  power  unit.  There  are  two  processing  groups  and  redundant  channel 
paths  to  the  peripheral  devices.  This  subsystem  fiimlshes  all  prime  channel 
interconnection  to  the  external  world.  Including  radar  Interfaces  and 
communication  to  other  ISSSs  and  the  SSCC. 

The  HCS  will  perform  the  air  traffic  computation  functions  with  new  controller 
workstations  that  replaced  the  Plan  View  Displays  (PVDs).  The  new  ISSS  equipment 
Is  connected  to  the  HCS  using  the  LCN.  The  ISSS  replaces  the  following  components 
of  the  HCS: 

a.  Computer  Display  Channel  (CDC) 

b.  Display  Channel  Complex  (DCC) 

c.  Display  Generators  <DGs) 

d.  Plan  View  Displays  (PVDs) 

e.  Flight  Strip  Printers  (FSP) 

f.  Associated  Interfaces  and  cables 

The  ISSS  completes  the  replacement  of  aging  9020  ATC  equipment,  which  was  started 
with  the  HOST  program. 

Two  of  the  three  HCS  System  Support  Facilities  at  the  Technical  Center  will  be 
reallocated  as  follows:  the  HCS  PAMRI  Services  Facility  (PSF)  will  become  part  of 
ISSS'2,  and  the  HCS  Alternate  Support  Facility  (ASF)  will  become  part  of  ISSS-1. 

3.4  INTERFACES. 

3.4.1  _ H9§T-lD^9lf4<P^- 

The  HOST  interface  Includes  the  hardware  and  software  In  the  LIUs .  Each  LIU 
consists  of  a  S/370  channel  adapter  attached  to  the  CCP,  which  Is  connected  via 
token  ring  adapters  to  the  LCN.  Two  LIUs  are  operated  redundantly  on  each  HOST 
processor. 

3.4.2  EDARC  System  Interface  (ESI). 

The  EDARC  system  Is  furnished  by  the  government  and  consists  of  up  to  14  display 
processors  and  2  control  processors  with  Interface  and  control  equipment  to  provide 
an  alternate  radar  processing  and  tracking  data  path. 
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The  ESI  stibsystem  equipment  is  housed  in  a  new  dual-bay  cabinet,  with  cables  to 
the  existing  EDARC  hardware.  Individual  Refresh  Output  Controllers  (ROCs)  Data 
?rocessor  (RDF)  circuit  cards  In  the  new  cabinet  attach  to  the  EDARC  Display 
Processors  by  a  cable  which  taps  the  display  refresh  data  stream.  The  processor 
In  each  RDF  monitors  the  display  data  stream  and  performs  comparisons  to  detect 
data  changes.  When  a  change  Is  detected,  the  prccessor  firmware  formulates  an 
update  message,  which  Is  sent  to  the  affected  sector,  via  the  Keyboard 
Communication  Processor  (KCP) ,  the  ESI  processor,  and  the  Backup  Communications 
Network  (BCN)  Controller  Input  messages  are  handled  by  the  KCF  and  Inserted  In 
the  EDARC  Input  as  If  they  were  keyboard  or  cursor  data  from  existing  devices . 
Controller  messages ,  which  are  composed  In  the  CC  and  transmitted  to  the  ESI  via 
the  BCN,  are  converted  to  "keystrokes”  In  the  KCP  processor.  Lexical  feedback  to 
the  controller  Is  handled  by  the  CC.  as  Is  cursor  movement.  When  cursor  position 
is  needed  In  EDARC,  the  position  Is  Included  In  the  message  by  the  CC.  This 
position  is  routed  to  EDARC  by  the  KCF  and  the  cursor  operation  Is  performed  by 
EDARC.  No  software  changes  In  EDARC  are  required.  The  only  hardware  changes  to 
the  existing  equipment  are  the  addition  of  the  Interface  cables  from  the  new 
cabinet  and  a  Radar  Controls  Multiplexer  (RCH)  circuit. 

3.4.3  Laboratory  Signal  Switching  System  (LSSS). 

The  Laboratory  Signal  Switching  System  (LSSS)  switches  digital  and  analog  radar 
sources,  and  modem  signals  to  the  SSCC.  The  digital  radar  messages  are  switched  to 
PAMRI  modem  splitters.  The  modem  splitters  route  the  radar  messages  to  the  F&SC  or 
to  one  of  the  EDARC  channels. 

4.  SYSTEM  OPERATIONS. 

1 .. .  AAg  9f EMTIOy?  • 

The  AAS  Job  Shop  provides  a  complete  development  and  support  environment  as  part  of 
the  SSCC  at  the  Technical  Center,  Including  the  capability  to  maintain,  update,  and 
generate  adaptation  data,  system  software,  and  documentation.  This  activity 
Includes  new  system  releases,  software  updates,  adaptation  data  updates,  and  CAS 
product  Integration.  The  Job  Shop's  CM  system  effectively  tracks  all  system 
modifications.  All  centers  have  remote  logon  capability  to  the  Job  Shop.  Table 
4.1-1  outlines  the  major  Job  Shop  functions,  users,  and  organizations  responsible 
for  support. 

The  support  software  that  provides  the  functionality  of  the  Job  Shop  is  divided 
Into  CSCIs,  each  of  which  provides  pieces  of  the  puzzle.  These  CSCIs,  and  their 
associated  functions,  are  listed  in  table  4.1-2,  SSCC  Support  Functions  and  their 
related  CSCIs. 

4.1.1  Configuration  Management  (CM). 

Approximately  2000  remote  users  at  different  levels  of  understanding  and  experience 
have  access  to  the  Job  Shop.  To  ensure  data  integrity  while  allowing  authorized 
access,  extensive  procedures  and  controls  are  in  place  to  allow  effective  and 
efficient  access.  The  Configuration  Management  (CM)  process  Includes  supporting 
future  release  plans  as  well  as  tracking  all  reported  problems  with  and  proposed 
changes  to  existing  ones.  The  planning  functions  for  adaptation  data,  logic,  and 
system  releases  are  based  on  the  use  of  an  ACI . 
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TABLE  4.1-1.  SSCC  SUPPORT  FONCTICMS  AND  THE 


JOB  SHOP  FUNCTIONS 

USERS 

Configuration  Control  and 
Management 

.  GN 
/OS 

?leld  Sites 

ACI  Process 

fCN 

aOS 

/ ield  Sites 

System  Release  Planning 

..OS 

Field  Sites 

Lc'glc  Release  Planning 

AOS 

Adaptation  Data  H?  nten- 
ance 

AOS 

Field  Sites 

Software  Developm  t  and 
Test 

ACN 

AOS 

Documentation  Mai:  enanc 

ACN 

AOS 

Field  Sites 

Resource  Scheduli 

ACN 

Hardware  Malntenanca 

ACN 

AOS 

Problem  Determination 


AOS 

Field  Sites 


RESPONSIBLE  ORGANIZATIONS 


SUPPORT 


ACN  Conflg  Team 
CCBs 


ACN 

AOS 


ACN 

AOS 

IBM  (1st  year) 


ACN 

AOS 

IBM  (1st  year) 


AOS 

Field  Sites 


ACN  * 

AOS:  j 

IBM  (1st  yijar)  * 


ACN 

AOS 

IBM' (1st  y?ar) 


ACN 


ACN 

AOS 

IBM  (1st  ytiar) 


AOS 

IBM  (1st  year) 


TABLE  4.1-2.  SSCC  SUPPORT  FUNCTIONS  AND  THEIR  RELATED  CSCIs 


CSCI  NAME 

ACRONYM 

SSCC  SUPPORT  FUNCTIONS 

Change  Control  and  Build 

CCAB 

Change  Tracking  and  Control 

CSCI  Document  Tracking 

Hardware  Symptom- Fix  Data 

Inventory  Management 

Job  Shop  Tools  Integration 

Library  Management 

Logic  Release  Archiving  and 

Restoring 

Maintenance 

Report  Generation 

Resource  Scheduling 

Requirement  Tracing 

Software  Build  Tools 

Version  Description  Document 

Conmon  System  Services 

CXSS 

Network  Configuration  and 

Management  for  FCC 

SSF  Configuration 

TIU/CCS  Simulation 

Display  Management 

DISP 

FCC  Input  Command  Processing 
Visual/Graphic  CHI  for  FCC 

Environment  Data  Collection 

ENVT 

Adaptation  Data  Collection  Adaptation 
Data  Configuration  Management 

MMI  Training  Support  Software 

MTSS 

Author  Lesson  Creation 

Detached  Console  Training 

NAS  Modifications 

NASM 

Simulation  Scenario  Creation 
Stand-Alone  Simulator  (SAS) 
Functionality 

Recording,  Analysis  and  Playback 

RAAP 

Data  Reduction  and  Analysis 

Display  Recording  and  Playback 

Failure  Reporting  Analysis  and 
Corrective  Action  System 
(FRACAS) 

SAR  Recording 

Site  Tailoring 

SITE 

Product  Construction 

Site-Specific  Adaptation  Data 

System  Release  Distribution 

System  Release  Planning 

TOOLS 

Environment  Support 
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All  changes  to  SSCC-1  are  tracked  and  docuaented  by  an  ACI.  The  ACT  is  the 
single  tracking  Instrument  for  all  AAS  problems  and  changes,  Including  changes 
to  hardware,  software,  adaptation  data,  and  baseline  documents  that  cover 
requirements,  design,  and  testing.  The  ACI  must  be  baselined,  reviewed,  tested, 
and  approved  before  any  changes  become  operational. 

There  are  two  kinds  of  ACIs:  change  ACIs  and  problem  ACIs.  Change  ACIs  are 
equivalent  to  Change  Requests  (CRs)  In  the  HCS  while  problem  ACIs  are  equivalent  to 
Program  Trouble  Reports  (PTRs)  In  the  HCS.  Both  kinds  of  ACIs  are  employed  by 
users  of  the  AAS  to  document  errors  or  deficiencies  In  Its  Implementation, 
operation,  or  documentation. 

In  general,  there  Is  little  difference  between  the  CM  life  cycle  of  the  two  kinds 
of  change  Instruments.  However,  there  Is  a  difference  In  the  ACIs  themselves.  The 
change  ACI  Is  used  when  the  operational  system  Is  functioning  as  required  but  may 
need  to  operate  differently,  and  the  problem  ACI  Is  used  when  the  operational 
system  Is  not  functioning  as  required  and  needs  to  be  fixed. 

A  user  may  open  an  ACI  from  any  ARTCC  by  remotely  logging  on  to  the  AAS  Job  Shop 
and  selecting  the  Change  Tracking  option  from  the  AAS  ATC  Operational  Support  and 
Tracking  Menu.  The  resulting  ACI  resides  In  the  database  at  the  SSCC  and  Is 
available  for  retrieval  by  authorized  SSCC  personnel  who  review  the  ACI  and  assign 
It  to  the  appropriate  analyst,  organization,  site,  or  other  authority.  Detailed 
Information  regarding  the  ten- step  ACI  life  cycle  Is  provide  In  appendix  A,  The 
Ten-Step  ACI  Life  Cycle. 


A  system  release  Is  a  collection  of  logic  updates  and/or  adaptation  data  products 
packaged  for  a  specific  ARTCC.  Each  new  system  release  Is  based  on  the  previous 
system  release.  There  are  two  kinds  of  system  releases;  base  and  delta. 

A  base  system  release  Is  a  complete,  executable  AAS  segment  system  consisting  of 
all  software  load  modules  and  corresponding  data  products  necessary  to  control  air 
traffic  at  a  particular  ARTCC.  Base  system  releases  are  distributed  Infrequently, 
approximately  once  per  year. 

A  delta  system  release  contains  a  subset  of  software  load  modules  and  Is  based  on  a 
system  release  which  has  been  baselined.  Delta  system  releases  occur  with  some 
frequency  and  may  or  may  not  be  coordinated  nationally.  The  Technical  Center 
generates  logic  changes  and  national  adaptation  changes.  Delta  releases  resulting 
from  these  changes  are  national  In  scope  and,  therefore,  are  coordinated 
nationally.  The  ARTCCs  handle  local  adaptation  data  changes  and  prepare  delta 
system  releases  as  dictated  by  local  needs.  A  delta  system  release  chains  all  the 
way  back  to  the  base  system  release. 


A  delta  system  release  may  consist  of: 

a.  Adaptation  data  products  only 

b.  Logic  release  data  sets  only 

c.  Both  logic  release  data  sets  and  adaption  data  products 

The  relationship  between  a  delta  and  a  base  system  release  Is  shown  In  figure 
A. 1.3-1,  Relationship  Between  a  Delta  Release  and  a  Base  Release.  For  more 
detailed  Information  regarding  adaptation  data  products  and  logic  release  data 
sets,  refer  to  appendix  .  Adaptation  Data  Update  Procedures,  and  appendix  C, 

Logic  Update  Procedures. 

&.I.3.1 _ Planning  a  System  Release. 

The  first  step  In  preparing  a  system  release  Is  planning  the  system  release  by 
using  the  System  Planning  function  of  the  AAS  ATC  Operational  Support  and  Tracking 
software.  The  system  release  plan  Identifies  which  logic  data  sets  and/or 
adaptation  data  products  are  to  be  Included  In  a  system  release.  A  system  release 
plan  has  two  stat\ises.  Pending  and  Baseline.  Pending  system  release  plans  can  be 
modified,  baseline  plans  cannot.  When  a  system  release  plan  has  a  status  of 
Baseline,  no  changes  can  be  made  and  the  plan  can  no  longer  be  constructed. 

_ Selecting  a  Logic  Release. 

When  planning  a  system  release,  a  logic  release  Identification  (ID)  and  a  site  ID 
must  be  specified.  If  the  system  release  being  used  contains  adaptation  data  only, 
then  the  logic  release  ID  Identifies  the  operational  logic  that  must  be  used  with 
the  adaptation  data  products  In  the  system  release.  The  logic  release  must  have 
been  created  previously  using  the  Logic  Release  Planning  functions  and  have  a 
status  of  at  least  OPEN. 

_ Specifying  Selection  Criteria  for  Adaptation  Data. 

Multiple  versions  of  the  same  data  may  be  stored  In  the  database,  therefore,  the 
user  must  establish  some  criteria  for  selecting  the  correct  version  of  the  data  to 
be  used  In  the  system  release.  Either  the  specific  version  of  the  data  must  be 
Identified  or  some  criteria  must  be  specified  to  enable  the  software  to  choose  the 
correct  version  of  the  occurrence. 

There  are  several  ways  to  determine  which  occurrences  are  to  be  used  In  the 
construction  of  the  data  products.  General  selection  criteria  such  as  the 
effective  data,  life  cycle  status,  and  occurrence  purpose  can  be  specified  to 
Influence  the  selection  of  occurrences  during  the  construction  process.  In 
addition.  Individual  occurrences  can  be  marked  for  Inclusion  In  or  exclusion  from 
the  construction  by  specifying  occurrence  overrides.  The  user  may  use  occurrence 
overrides  to  make  single  change  while  protecting  the  system  release  from  any  other 
changes.  Furthermore,  the  data  selection  has  the  ability  to  show  preference  to 
occurrences  created  under  certain  ACIs  for  a  particular  system  release. 
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FIGURE  A. 1.3-1.  RELATIONSHIP  BETWEEN  A  DELTA  RELEASE  AND  A  BASE  RELEASE 


After  the  data  occurrences  for  a  system  release  are  chosen,  the  data  is  converted 
into  data  products,  a  computer  readable  form  of  data  occurrences.  A  construction 
list  is  required  in  order  to  include  adaptation  data  in  a  system  release. 

The  construction  list  specifies  which  data  products  are  to  be  constructed  for  the 
system  release.  The  user  may  select  the  data  products  directly  or  indirectly. 
Either  the  user  specifies  directly  which  data  products  will  be  part  of  the  system 
release,  or  the  user  specifies  which  categories  of  data  or  which  ACIs  are  to  be 
processed  and  allows  the  System  Release  Planning  function  to  determine  which  data 
products  to  build. 

When  categories  are  selected  for  a  system  release,  a  predefined  category  to  data 
product  map  is  used  to  determine  which  data  products  to  construct.  When  ACIs  are 
selected  for  a  system  release,  the  software  determines  which  categories  are 
referenced  by  that  ACI,  and  then  uses  the  same  category  to  data  product  map  to 
determine  which  data  products  to  construct.  Only  data  products  can  be  deployed  to 
a  center.  Categories  cannot  be  deployed  to  a  center. 

When  a  system  release  plan  is  created,  it  Includes  a  construction  list  containing 
all  of  the  data  products  for  the  specified  logic  release.  For  a  base  system 
release,  there  is  a  fixed  number  of  data  products  and  the  system  requires  these 
data  products  in  order  to  execute  successfully.  Thus,  when  a  base  plan  is  created, 
a  construction  list  is  automatically  generated  and  cannot  be  changed.  The  user, 
however,  must  still  identify  the  specific  data  occurrences  to  be  used  to  construct 
the  data  products. 

When  a  delta  system  release  plan  is  created,  the  construction  list  is  copied  from 
the  system  release  plan  upon  which  the  delta  plan  is  based,  or  from  another  system 
release  specified  by  the  user. 

4. 1.3. 1.4  ConstructinE  Data  Products. 

Adaptation  data  as  it  is  collected  and  stored  is  not  usable  by  the  operational 
software.  Before  the  data  can  be  used  by  the  operational  software  at  an  ARTCC,  it 
must  be  converted  into  data  products.  An  adaptation  data  product  is  a  constructed 
adaptation  object  file  consisting  of  source  adaptation  data  values  that  have  been 
converted  to  the  form  required  by  the  AAS  real-time  application  software. 

The  sequential  data  sets  that  comprise  the  data  products  to  be  used  with  a  system 
release  are  stored  in  MVS  files.  These  data  products  are  unique  to  each  ARTCC. 

Adaptation  data  products  are  defined  by  an  Ada  typing  package.  Because  the  data 
collector's  view  of  the  data  is  likely  to  be  quite  different  from  the  way  the 
operational  software  needs  to  access  that  data,  a  particular  category  does  not 
necessarily  correspond  to  only  one  data  product. 
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Data  construction  Is  perfomed  in  the  background  because  of  the  asiount  of 
processing  tine  required  for  this  task.  The  user  may  select  a  subset  of  the  data 
products  to  be  constructed  for  a  system  release.  Constructing  only  a  few  data 
products  at  a  time  allows  the  user  to  check  the  results  of  the  construction  and 
correct  any  problems  before  continuing.  This  checking  is  important  because  if  the 
construction  of  a  data  product  falls,  the  subsequent  construction  of  related  data 
products  may  also  fail. 

4 .-1  ■  ? . 2 _ Test  Shipping  a  System  Release. 

Test  shipping  allows  the  user  to  ship  a  pending  or  baseline  system  release  to  an 
ARTCC  or  to  the  SSF  for  testing.  This  gives  the  user  the  ability  to  fully  test  the 
system  release  and  to  make  any  necessary  changes  before  it  is  baseline.  (A 
baseline  system  release  cannot  be  modified,  which  means  that  any  errors  found  in  a 
baseline  system  release  may  be  corrected  only  by  creating  another  baseline  system 
release . ) 

A  test  shipment  may  contain  a  subset  of  a  system  release's  adaptation  data  or 
logic.  Rather  than  ship  a  complete  system  release,  the  user  may  choose  to  ship  a 
subset  of  the  system  release.  The  user  selects  the  desired  adaptation  data  or 
logic  and  ships  it  to  the  desired  facility.  This  feature  is  useful  because  the 
system  release  has  not  been  baselined  and  the  logic  release  may  not  yet  have  been 
marked  deployable.  The  deployment  control  file  Identifies  the  system  release  as  a 
test  shipment.  No  deployment  record  is  created.  Report  receipt  and  report  cutover 
cannot  be  performed,  even  if  a  complete  system  release  is  shipped. 

4. 1.3. 3  Deploying  a  System  Release. 

The  act  of  sending  a  complete,  successfully  tested  system  release  from  the 
Technical  Center  to  the  ARTCC  is  referred  to  as  the  deployment  of  the  system 
release.  The  system  release  is  deployed  to  the  ARTCC  by  selecting  the  Deploy 
System  option  on  the  System  Distribution  Panel,  which  is  an  option  on  the  AAS  ATC 
Operational  Support  and  Tracking  Menu.  A  system  release  must  meet  several  criteria 
before  it  can  be  deployed  to  an  ARTCC  for  use  as  operational  software: 

a.  The  logic  release  associated  with  the  system  release  must  have  a  status  of 
DEPLOY,  even  if  the  logic  itself  is  not  being  deployed  with  the  system  release. 

b.  All  data  products  must  have  been  constructed  successfully. 

c.  The  system  release  plan  must  have  been  baselined.  A  baseline  system 
release  plan  can  no  longer  be  modified.  The  selection  criteria  and  construction 
list  cannot  be  changed  and  the  data  products  cannot  be  reconstructed  for  that 
system  release. 

When  these  standards  are  met,  the  system  release  is  ready  for  deployment  to  the 
ARTCC.  Base  system  releases  and  large  delta  system  releases  are  deployed  to  the 
ARTCCs  by  loading  the  system  release  files  onto  tapes  and  physically  shipping  the 
tapes  to  the  ARTCCs.  An  electronic  link  is  used  for  deploying  relatively  small 
delta  system  releases. 
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There  are  two  stages  to  the  deployaent  process.  The  first  stage  verifies  the 
existence  of  each  data  set  to  be  distributed  and  tailors  the  distribution  Job  via 
a  background  Job.  If  there  are  no  errors  in  the  first  stage,  the  distribution  Job 
is  autonatically  submitted  to  perform  the  second  stage.  The  second  stage 
processing  creates  the  deploy  headers  which  contain  information  about  each  of  the 
files  that  make  up  the  system  release,  performs  check  sum  processing  to  ensure  that 
files  were  not  corrupted  during  the  deployment,  and  copies  the  required  files  to 
tape  or  transmits  them  over  the  electronic  link,  %fhichever  is  appropriate. 

4.1.4  Adaptation  Data. 

According  to  the  centralized  software  maintenance  concept,  all  ARTCCs  must  use  the 
same  operational  software  for  ATC.  Since  each  ARTCC  has  different  needs,  it  is 
necessary  to  have  a  method  of  customizing  the  software.  To  meet  these  needs,  each 
ARTCC  \ises  site  specific  sets  of  data.  The  term  adaptation  describes  the  process 
of  making  the  operational  software  capable  of  performing  ATC  functions  at  a 
particular  ARTCC.  Adaptation  of  the  logic  is  performed  throu^  this  special  set  of 
data,  and  conversely,  the  operational  software  needs  this  adaptation  data  in  order 
to  provide  ATC  services  at  each  ARTCC. 

Many  ARTCC- specific  changes  can  be  accomplished  by  updating  only  the  adaptation 
data.  For  this  reason,  the  operational  software  is  designed  to  be  table  driven. 

The  behavior  of  the  software  is  dependent  on  certain  data,  stored  in  tables,  that 
is  kept  separate  from  the  logic  so  that  the  data  can  be  changed,  when  necessary,  in 
a  relatively  simple  manner.  This  design  eliminates  the  need  to  modify  and  retest 
the  operational  software  each  time  a  data  change  is  made. 

Adaptation  data  describes  the  geographical,  physical,  and  operational  environment 
within  which  an  ARTCC  operates.  Geographical  and  physical  data  describe  a 
particular  center's  environment  while  operational  data  alters  how  the  operational 
software  performs. 

Geographical  adaptation  data  includes  static  maps  and  text,  airport  and  fix 
locations,  and  terrain  (minimum  safe  altitude)  information.  Physical  adaptation 
data  describes  computer  hardware  elements,  aircraft  characteristics,  and  radar 
characteristics.  Operational  adaptation  data  includes  such  data  as  ISSS  display 
definitions,  air  space  definitions,  system  parameters,  and  radar  sort  boxes. 

Adaptation  data  can  be  divided  into  two  categories:  preset  data  and  facility  data. 
Preset  adaptation  data  is  built  and  tested  as  part  of  a  logic  release.  Facility 
adaptation  data  tailors  the  operational  software  to  the  specific  requirements  of 
each  ARTCC.  Figure  4. 1.4-1  shows  the  adaptation  data  types. 

4 .1.4.1  Preset  Data. 

Preset  adaptation  data,  such  as  command  formats  and  command- related  error  messages, 
is  built  and  tested  as  part  of  a  logic  release  at  the  Technical  Center.  It  is  the 
same  for  all  ARTCCs  and  cannot  be  changed  by  those  centers.  The  AOS  software 
developers  who  modify  the  operational  software  use  the  SCLM  development  environment 
with  special  tools  to  prepare  preset  adaptation  data.  Site  adaptation  data 
specialists  do  not  enter  or  maintain  preset  adaptation  data. 
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FIGURE  4.1.A-1.  ADAPTATION  DATA 
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Because  preset  adaptation  data  Is  associated  with  a  given  logic  release  and  is  not 
changeable  by  each  ARTCC,  the  CM  requirenents  on  preset  adaptation  data  are 
different  from  those  for  other  adaptation  data.  Once  preset  adaptation  data  is 
entered,  the  data  is  associated  with  the  appropriate  logic  release  and  is  moved 
into  the  data  sets  containing  that  logic  release.  These  data  sets  are  controlled 
using  the  SCLM. 

4>1.4.2 _ Facility  Data. 

Facility  adaptation  data  adjusts  the  operational  software  to  suit  the  needs  of  a 
specific  ARTCC,  therefore,  the  data  differs  from  one  center  to  another.  Facility 
adaptation  data  can  be  further  subdivided  into  national  and  local  data.  FAA 
authorization  procedures  control  whether  data  is  classified  as  national  or  local. 
This  classification  limits  who  can  enter  or  change  the  values  of  each  type  of  data. 

National  facility  adaptation  data  is  data  that  is  collected  and  maintained  at  the 
SSCC  and  used  by  all  ARTCCs.  National  facility  adaptation  data  cannot  be  modified 
by  ARTCC  personnel.  The  data  is  updated  regularly  by  authorized  AOS  personnel  in  a 
cycle  which  is  described  in  appendix  B,  Adaptation  Data  Update  Procedures.  Since  a 
particular  center  does  not  necessarily  use  all  of  the  national  adaptation  data, 
center  personnel  may  select  the  data  they  wish  to  use.  Static  information  charts 
and  textual  information  such  as  the  Airman's  Information  Manual  are  t}rpical 
examples  of  national  adaptation  data. 

Local  facility  adaptation  data  is  completely  defined  and  managed  by  each  ARTCC. 
Local  data  consists  of,  for  example,  the  hardware  configurations,  geographical 
boundaries,  and  sectorlzation  data  for  a  specific  ARTCC.  This  data  is  generally 
meaningful  only  to  the  center  that  defines  it. 

^.1.^.3 _ Organization  of  Adaptation  Data. 

Adaptation  data  is  subdivided  and  categorized  so  it  can  be  stored  and  managed  in 
self-contained  units  that  are  closely  associated  with  the  physical  world  and 
related  personnel  responsibilities.  Adaptation  data  is  organized  according  to  a 
hierarchy  consisting  of  data  items,  categories,  occurrences,  and  families. 

An  adaptation  data  item  defines  one  field  in  the  adaptation  record,  such  as  a 
processor  ID  or  a  threshold  value.  Related  data  items  that  are  to  be  collected  and 
maintained  as  a  unit  are  grouped  into  categories. 

A  category  is  a  group  of  related  data  items  organized  around  real-world  objects. 

It  is  tailored  to  the  data  collector's  view  of  adaptation  data. 

An  occurrence  is  a  particular,  unique  instance  of  a  category  in  which  values  are 
provided  for  the  data  items  in  the  category.  Adaptation  data  items  within  a 
particular  category  are  collected  and  maintained  as  an  occurrence.  An  occurrence 
is  the  lowest  level  of  granularity  for  adaptation  planning,  collection,  and  CM 
functions.  Occurrences  are  also  the  lowest  level  of  adaptation  data  that  can  be 
selected  for  a  system  release.  A  given  category  may  require  one  or  more 
occurrences  for  each  ARTCC. 
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An  adaptation  data  family  Is  a  collection  of  related  categories.  It  reflects  a 
knowledge  set  for  %rhlch  a  data  collector  may  be  responsible  and  provides  various 
processing  paths  for  accessing  the  categories. 

4. 1.4.4  Nominal  Values. 

During  development  and  testing  of  the  operational  software,  certain  values  for  some 
adaptation  data  occurrences  have  been  identified  as  optimum,  meaning  that  they 
worked  well  under  many  circumstances.  These  values  are  called  nominal  values  and 
may  be  copied  Into  new  occurrences.  Users  may  request  a  report  that  lists  all 
nominal  values. 

4. 1.4. 5  Related  CSCIs. 

Adaptation  data  Is  processed  by  the  ENVT  and  SITE  CSCIs.  The  ENVT  CSCI  provides 
the  user  interface  and  supporting  functions  for  collecting  and  maintaining 
adaptation  data  In  DB2.  The  SITE  CSCI  provides  the  user  Interface  and  supporting 
functions  for  preparing  system  releases  to  run  on  the  ATC  computers  at  the  ARTCCs. 
These  functions  allow  the  user  to  plan  a  system  release,  construct  data  products, 
and  distribute  a  system  release.  Both  ENVT  and  SITE  Interface  with  the  CCAB  CSCI, 
as  well. 

The  CCAB  provides  ENVT  with  tracking  Information  on  adaptation  data  changes  and  on 
software  changes  associated  with  data  changes,  while  ENVT  provides  CCAB  with  the 
status  of  adaptation  data  changes.  The  ENVT  also  maintains  the  authorization  list 
that  CCAB  and  SITE  use  to  verify  a  user's  authorization  to  perform  a  requested 
function. 

The  SITE  uses  CCAB  to  determine  which  logic  release (s)  are  to  be  associated  with  a 
system  release,  and  uses  the  data  stored  by  CCAB  to  verify  AAS  logic  release  names. 
SITE  provides  CCAB  with  system  planning  Information  for  reporting.  The  CCAB 
provides  SITE  with  the  list  of  logic  data  sets  comprising  a  logic  release  and 
compatibility  data  used  to  control  planning  and  constructing  data  products  that 
will  be  used  In  the  logic  release. 

4. 1.4. 6  Adaptation  Data  Update  Procedures. 

The  ACI  is  the  tool  ixsed  to  keep  track  of  all  changes  to  adaptation  data.  Once  an 
ACI  has  been  opened  for  an  adaptation  data  occurrence,  data  may  be  added  or 
modified  using  the  Data  Collection  function  of  the  AAS  ATC  Operational  Support  and 
Change  Tracking  software. 

The  term  data  collection  Is  used  to  describe  the  process  of  entering  new  or 
modifying  existing  adaptation  data.  Adaptation  data  is  collected  and  maintained  at 
the  SSCC  as  part  of  the  centralized  maintenance  concept.  This  enables  the 
personnel  who  are  responsible  for  site  adaptation  of  the  AAS  operational  software 
to  access  it  as  needed.  Center  personnel  log  on  to  the  SSCC  remotely  and  enter  or 
update  adaptation  data  pertaining  to  teir  center  by  using  the  Data  Collection 
function  of  the  AAS  ATC  Operational  Support  and  Change  Tracking  software. 
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Adaptation  data  nay  be  entered  or  oodlfled  by  nany  different  users,  at  all  times  of 
the  day  or  night,  and  for  many  purposes,  Including  test,  problem  correction,  and 
future  planning.  If  unapproved  data  Is  selected,  appropriate  error  and  warning 
messages  are  generated  to  ensure  that  such  selection  Is  properly  flagged.  This  CM 
step  provides  protection  against  Inadvertent  errors,  da  transmission  errors,  and 
outright  attempts  at  sabotage.  Strict  conformance  to  CM  guidelines  Is  required  to 
maintain  system  integrity. 

Making  changes  to  adaptation  data  Involves  a  series  of  actions.  The  specific  steps 
required  to  make  a  change  to  adaptation  data  depend  on  the  circumstances  and  the 
particular  adaptation  task  being  performed.  The  general  procedure  for  updating 
adaptation  data  Is  as  follows: 

a.  Open  an  ACl  using  the  Change  Tracking  function  of  the  Support  Software. 

b.  Add,  maintain,  and  configuration  manage  adaptation  data  using  the  Data 
Collection  function. 

c.  Plan  a  system  release  Incorporating  adaptation  data  updates  using  the 
System  Planning  function. 

d.  Construct  data  products  from  the  adaptation  data  occurrences  using  the 
Data  Construction  function. 

e.  Deploy  the  system  release  to  an  ARTCC  using  the  System  Distribution 
function. 

These  functions  are  illustrated  In  figure  4. 1.4. 6-1,  Support  Software  Processing  of 
Adaptation  Data.  Detailed  Information  on  making  changes  to  adaptation  data  Is 
provided  In  appendix  fi.  Adaptation  Data  Update  Procedures. 

ULi _ LPfci<r  R^leqge. 

A  logic  release  is  a  set  of  related  operational  software  used  to  generate  a 
deliverable  system.  A  logic  release  may  be  as  small  as  a  single  software  element. 
This  allows  the  release  of  emergency  corrections  to  resolve  critical  operational 
problems.  The  logic  release  may  be  a  combination  of  several  operational  changes. 
Some  possible  items  In  a  logic  release  are  Ada  source  and  executable  load 
module(s).  Job  Control  Language  (JCL) ,  MVS,  and  TSO  commands  In  a  Command  List 
(CLIST) . 

A  logic  release  plan  Is  a  collection  of  Information  about  a  logic  release  which 
includes  a  schedule  for  building  and  promoting  a  logic  release  and  a  record  of  all 
the  ACIs  and  associated  software  and  docximents  that  are  Included  In  the  logic 
release.  A  logic  release  plan  is  necessary  to  develop  and  deliver  a  logic  release. 

There  are  two  types  of  logic  releases;  base  and  delta.  A  base  logic  release 
contains  a  full  set  of  logic.  A  delta  logic  release  contains  a  subset  of  the 
logic.  A  delta  release  is  used  when  only  a  portion  of  the  logic  is  being  replaced 
and  contains  only  the  components  to  be  replaced.  A  delta  logic  release  chains  back 
to  the  base  logic  release. 
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4. 1.4. 6-1.  SUPPORT  SOFTWARE  PROCESSING  OF  ADAPTATION  DATA 
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Logic  release  files  are  the  software  components  which  comprise  a  logic  release. 

The  logic  release  plan  identifies  which  logic  release  files  will  be  Included  in  a 
particular  base  or  delta  logic  release.  The  user  identifies  which  logic  release  is 
to  be  associated  with  the  planned  system  release  using  the  System  Release  Planning 
function. 

The  AAS -developed  code  and  documentation  is  maintained  in  a  hierarchical  library 
management  system,  l.e.,  SCLM.  The  SCLM  administrators  are  ACN-600  personnel.  The 
SCLM  administrators  set  up  the  library  for  a  new  release  of  doc'^UttenLation  or  code, 
allocates  the  necessary  datasets,  and  defines  the  necessary  library  hierarchy.  The 
hierarchy  Is  defined  with  a  SCLM  project  definition.  This  project  definition 
identifies  all  library  types  and  sections  necessary  for  the  development,  testing, 
and  deployment  of  the  logic  release.  Once  the  SCLM  project  definition  Is  defined. 
It  must  be  assembled  under  SCLM  using  the  Library  Definition  Translator  provided  by 
AAS.  This  creates  the  logic  release  plan  with  a  status  of  NEW  and  the  logic 
release  plan  Is  ready  to  be  opened  by  the  AOS  software  developers. 

Operational  logic  Is  updated  by  AOS  personnel  using  the  AAS  Operational  Support 
and  Tracking  software.  The  revised  logic,  in  the  fonn  of  a  logic  release.  Is 
available  for  deployment  to  the  ARTCC(s)  according  to  a  cycle  which  Is  outlined 
in  appendix  C,  Logic  Update  Procedures. 

^.1.5.1 _ Logic  Update  Procedures. 

The  ACI  is  the  tool  used  to  keep  track  of  all  changes  to  operational  software. 

Once  an  ACI  has  been  opened  for  the  operational  software,  logic  may  be  added  or 
modified  using  the  Logic  Planning  function  of  the  AAS  ATC  Operational  Support  and 
Change  Tracking  software. 

The  procedure  for  updating  operational  software  consists  of  several  general 
fxmctions,  each  of  which  has  associated  subfunctions.  Although  the  general 
functions  are  required  in  order  to  make  the  changes.  In  many  cases  the  specific 
tasks  within  a  major  function  can  be  done  in  a  somewhat  different  order  or  by  a 
different  organization. 

The  major  steps  for  developing  software  are  as  follows: 

a.  Open  and  process  an  ACI 

b.  Assign  the  ACI  to  a  logic  release 

c.  Develop  the  software 

d.  Unit  test  the  software 

e.  Integrate  and  test  the  software 

f.  Update  documentation 

g.  Install  the  new  software  Into  the  production  environment 

Detailed  information  regarding  the  logic  update  procedures  is  provided  in 
appendix  C ,  Logic  Update  Procedures . 
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All  code  will  be  developed  and  tested  in  the  AAS  Job  Shop  at  the  Tachnical  Center. 
There  ere  several  software  languages  used  in  the  AAS  code.  Ada  is  the  primary 
language.  Ada  code  can  be  developed  and  unit  tested  using  the  Rational  RIOOO 
system  or  the  NCF.  Other  software  languages  used  to  interface  with  the  commercial 
software  products  in  AAS  include  Cross  System  Product  (CSP),  Assembler  H  (INFO). 
ISPF  Language/SCLM  Requirements  File  (REXX),  CLIST,  ISFF,  and  Assembly.  These  .re 
languages  for  the  support  system,  and  they  will  be  developed  and  unit  tested  on  the 
Job  Shop.  All  code  is  integration  tested  on  the  Eagle  RISC- 9000  processor.  The 
Eagle  RISC- 9000  processor  is  the  upgraded  version  of  the  RISC -6000  processor 
capability. 

The  central  processing  complex  will  provide  the  software  development  base.  It  vrlll 
provide  automated  compilation,  build  control,  and  centralized  CM  for  all  developed 
software.  The  Rational  R-1000,  consisting  of  specialized  processors,  terminals, 
and  software  will  provide  dedicated  Ada  support  suitable  for  the  development  of 
software  througih  ftmctional  unit  test.  The  programmable  workstations  will  prov  ’  de 
the  eagle  environment  for  unit  testing  Ada  code. 


The  software  malntainer  tises  SCLM  to  edit,  build,  and  promote  source  code,  such  as 
Ada,  stored  in  partitioned  data  sets  on  MVS.  The  SCUM  build  function  is  used  i 
compile,  link,  and  integrate  software  components.  SCLM  stores  and  makes  avails  le 
on-line  two  versions  of  the  software  for  each  operational  AAS  facility. 
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Software  Development  Procedures. 


Under  AAS,  all  system  changes  must  be  identified  by  ACIs.  Tais  includes 
modification  of  existing  software  and  addition  of  new  softwt’re  functions.  logic 
Maintenance  follows  the  steps  outlined  for  a  problem  ACI.  logic  update  procedt:res 
are  outlined  in  section  4.1.5,  Logic  Release. 


1.6.2 
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CAS  products  and  AAS-developed  computer  software  subsystems,  will  be  used  with 
the  AAS  Job  Shop.  Such  program  development  support  software  includes  compilers  . 
assentblers,  dialogue  managers,  application  generators,  editers,  and  documentat '  n 
tools.  Ada  will  be  the  primary  language  used  for  AAS  software  development. 


4.1. 6.2.1  Ada. 

The  IBM  Development  System  for  the  Ada  Language  operates  in  the  AAS  Job  Shop  at  :lis 
SSCC  and  provides  Hl^-Order  Language  (HOL)  compilation  support  of  AAS-develop 
software.  It  includes  an  Ada  programming  support  environment,  providing  tools  .ch 
as: 

a.  Cross-referencing  tools 

b.  Interactive  development  support  tools 

c.  Debugging  aids  and  testing  tools 

d.  Standard  compliance  and  verification  tools 

The  IBM  Development  System  for  the  Ada  Language  System/370  provides  an  Ada 
compiler,  a  run-time  library,  a  global  optimizer,  and  a  symbalic  debugger  for 
application  development  on  the  System/370  under  MVS/XA. 
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The  MVS  Ada  conpller  both  compiles  and  binds.  The  compiler  processes  Ada  source 
files,  producing,  and  storing  object  code  in  the  Ada  program  library.  The  binder 
links  the  object  code  in  the  library  to  produce  an  object  file.  The  compiler  uses 
the  MVS  linkage  editor,  making  the  object  file  executable.  The  Ada  source  can  be 
either  an  entire  or  a  partial  program.  The  Ada  source  file  can  include  the 
following: 

a .  Main  Program 

b .  Package  Body 

c.  Package  Specification 

d.  Other  Ada  compilation  units 

The  use  of  compilation  units  allows  the  construction  of  large  Ada  programs  from 
small,  maintainable  program  portions.  The  compiler  generates  syntax  and  semantic 
error  messages  when  necessary.  If  there  are  syntax  and  semantic  errors,  the 
compiler  does  not  generate  object  code.  The  binder  links  together  object  code  for 
compilation  units  which  need  to  access  each  other  during  run  time.  When  an  entire 
Ada  program  executes,  the  compiler  generates  object  code  for  the  Ada  main  program, 
which  is  the  compilation  unit  receiving  control  first.  It  then  accesses  the  Ada 
program  library  and  links  together  all  object  code  generated  for  each  compilation 
unit  of  the  Ada  program.  The  binder  produces  bound  object  code  in  the  IBM 
System/370  object  format  which  is  then  ready  to  be  link-edited  and  executed. 

The  run-time  libraries  allow  application  execution  on  a  System/370  processor  other 
than  the  one  used  for  development.  The  application's  load  module  can  be 
transferred  to  other  machines  where  run-time  librairy  routines  will  be  called  during 
application  execution.  The  IBM  Ada  Rvtn-Time  Environment  S/370  operates  in  all  AAS 
System/370  central  processors,  allowing  execution  of  Ada  applications  compiled  in 
the  AAS  Job  Shop. 

The  Global  Optimizer  works  in  conjunction  with  the  Ada  compiler.  The  main  job  of 
the  Global  Optimizer  is  to  make  the  Ada  code  more  efficient.  It  optimizes  global 
components  of  HOL  to  increase  the  performance  of  Ada  code. 

The  MVS  Symbolic  Debugger  allows  users  to  examine  the  behavior  of  an  executing  Ada 
program  as  if  the  Ada  source  Itself  were  executing.  It  is  a  source -level  debugger 
because  it  allows  users  to  work  with  Ada  source  construction  imlts  like  lines  of 
code  and  compilation  units .  It  is  also  a  symbolic  debugger  because  it  lets  users 
work  with  Ada  data  objects  using  symbolic  names  instead  of  machine -code  values. 

4. 1.6. 2. 1.1  Ada  Support  Environment  Tools. 

The  MVS  Ada  Programming  Support  Environment  (APSE)  is  an  AAS-developed  front-end  to 
the  IBM  commercial  product  Interactive  System  Productivity  Facility /Program 
Development  Facility  (ISPF/PDF)  which  allows  user  to  analyze  Ada  source  code, 
format  it,  and  generate  various  output  files  based  on  the  input  of  the  Ada  source 
code.  Ada  has  several  tools  that  provide  this  functionality.  These  tools  are: 

a.  The  Ada  Debugger  Interface  Tool.  Provides  an  ISPF/PDF  panel  that  allows 
full-screen  interaction  between  the  MVS  Ada  Symbolic  Debugger  and  the  user.  Before 
using  the  tool,  the  user  must  allocate  a  data  set  named  DEBUG . LIBRARY  with  the 
user's  USERID  as  the  high-level  qualifier.  Users  can  run  this  tool  in  either 
foreground  or  background  mode. 
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b.  The  Ada  Complexity  Tool.  Provides  an  ISPF/PDF  panel  that  allows  the  user 
to  specify  the  name  of  one  or  more  Ada  source  files  for  computing  the  complex 
nu]d>er  for  all  program  units  in  the  source  code.  The  tool  uses  the  HcCabe 
complexity  nui^er  as  a  standard,  and  provides  a  breakdown  of  splitting  nodes  and  a 
normalized  coisplexlty  number  for  the  Ada  source  code  the  user  wanted  to  measure. 
Users  can  run  this  tool  in  either  foreground  or  background  mode. 

c.  The  Ada  Source  Counter  Tool.  Provides  an  ISPF/PDF  panel  that  allows  the 
user  to  specify  the  name  of  one  or  more  Ada  source  files  for  computing  sets  of 
statistics  with  respect  to  the  source  code.  The  tool  counts  semicolons,  Ada  lines, 
comments,  and  Ada  statements,  and  then  categorizes  Ada  statements  into  executable, 
declarative,  and  directive  functions.  Users  can  run  this  tool  in  either  foreground 
or  background  mode. 

d.  The  Ada  Source  Formatter  Tool.  Provides  an  ISPF/PDF  panel  that  allows  the 
user  to  specify  the  name  of  one  or  more  Ada  source  files  for  formatting  to  comply 
with  all  established  AAS  project  standards  and  guidelines.  The  user  can  invoke  the 
tool  vising  the  AAS*developed  edit  macro  FORMAT  while  editing  a  partitioned  data  set 
under  AASPDF.  Users  can  run  the  panel  interface  version  of  this  tool  in  either 
foreground  or  background  mode. 

e.  The  Ada  Publisher  Tool.  Provides  an  ISPF/PDF  panel  that  allows  users  to 
specify  the  name  of  one  or  more  Ada  source  files  for  formatting  to  produce  output 
that  can  be  further  processed  using  SCRIPT/VS  or  Bookmaster  to  yield  attractive 
hardcopy  output  of  source  code.  The  docvunent  contains  a  title  page,  table  of 
contents,  and  highlights  Ada  keywords  in  boldface  type.  Users  can  run  this  tool  in 
either  foreground  or  background  mode.  If  the  user  runs  the  tool  in  foreground,  the 
tool  invokes  EZPrlnt  at  the  completion  of  processing  to  allow  the  user  to  print  the 
formatted  document. 

_ Ada  Maintenance  Using  the  NCF. 

The  NCF  allows  the  IBM  3090  to  communicate  with  the  RISC  System/6000  for  performing 
Ada  compilations  of  RISC- targeted  code.  The  source  code  and  compiler  outputs  are 
configuration  managed  on  the  3090  under  SCLM.  The  compiles  are  performed  on 
RISC/6000  processors  via  a  networking  mechanism  invoked  from  the  3090.  There  are 
three  types  of  commands  that  SCLM  is  able  to  request  from  the  NCF: 

a.  Ada  compile 

b .  Ada  Bind 

c .  Ada  Promote /Purge 

The  compile  function  is  used  to  add  or  update  an  Ada  compilation  unit  to  an  Ada 
sublibrary  and  generate  its  object  code.  When  users  invoke  the  compile  function, 
SCLM  determines  what  work  needs  to  be  done  to  compile  the  unlt(s) .  This  work  is 
relayed  to  one  of  the  dedicated  NCF  RISC  Processors.  Upon  completion  of  the  work, 
the  NCF  RISC  sends  back  its  results.  The  SCLM  then  scans  the  results  for  success 
or  failure  return  codes  and  updates  its  database  and  files  accordingly. 
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The  bind  function  Invokes  the  compiler  binder  and  Advanced  Interactive  Executive 
(AIX)  linker  on  a  dedicated  RISC  and  generates  a  RISC-targeted  executable  file 
which  is  retained  under  SCLM  control.  When  the  user  invokes  the  bind  function, 
scut  determines  tdiat  sublibraries  are  needed  to  perform  the  bind  and  creates  an 
executable.  The  list  of  sxiblibraries  and  required  linker  system  files  are  sent 
to  one  of  the  dedicated  NCF  RISCs.  Upon  completion  of  the  work,  the  NCF  RISC 
sends  back  its  results  and  the  executable  code.  SCLM  then  scans  the  results  for 
success  or  failure  return  codes  and  updates  its  database  accordingly.  Results  of 
the  bind  can  be  found  in  the  MVS  job  queue  output.  The  executable  code  can  be 
found  in  the  SCLM- controlled  partitioned  data  set  for  executables. 

The  purge  and  promote  functions  allow  for  copy  and  removal  of  one  or  more  RISC- 
targeted  compilation  units  from  their  sublibraries  as  well  as  the  copy/removal 
of  their  corresponding  SCLM  database  records.  When  the  \iser  invokes  the  purge 
or  promote  function,  SCLM  determines  what  needs  to  be  done  to  compile  the  unit(s) . 
This  work  is  relayed  to  one  of  the  dedicated  NCF  RISCs.  Results  of  compilation 
can  be  found  in  the  MVS  job  queue  output.  The  Ada  sublibraries  and  archived 
object  code  containing  data  associated  with  the  compiled  unit(s)  are  updated 
under  MVS  third- level  qualifier. 

4. 1.6. 2. 1.3 _ Software  Development  Tools. 

Software  development  and  maintenance  tools  for  the  RISC  System/6000  are  divided 
into  two  categories:  IBM  3090-resident  and  RISC  6000 -resident.  The  3090-resident 
tools  are: 


a.  Software  Configuration  and  Library  Manager  (SCLM)  is  a  CM  tool  that  is 
used  for  logic  development  and  maintenance.  It  is  an  extension  of  ISPF/FDF  and  has 
procedures  for  building,  manipulation,  and  tracking  data  stored  in  the  AAS  project 
databases.  The  SCIM  enables  a  user  to  build,  promote,  browse,  create,  edit, 
update,  and  delete  data  stored  in  a  data  library.  These  functions  are  automated 
under  SCLM. 

b.  System  Display  and  Search  Facility  (SDSF)  is  a  useful  tool  on  MVS.  While 
using  SDSF  panels,  users  can  hold,  release  jobs,  cancel  jobs,  find  out  if  jobs  are 
being  processed  or  waiting  to  be  processed,  view  output  before  it  is  printed,  print 
selected  portions  of  a  job's  output,  or  purge  a  job's  output. 

c.  Cross-Compiler  and  Cross-Linker  C  language  code  that  resides  on  the  IBM 
3090  under  MVS/XA  is  processed  for  use  on  the  RISC  System/6000  processor.  The  C 
compiler  reads  C  source  files  and  generates  assembly  language  that  the  assembler 
translates  to  object  modules.  Once  object  modules  are  created,  the  IBM  linkage 
editor,  or  loader,  combines  the  object  modules  with  appropriate  members  from  the 
C  library  and  generates  an  executable  file. 

d.  Ada  MVS  Debugger  Interface.  This  tool  is  an  interface  between  the  MVS  Ada 
Symbolic  Debugger  and  the  IBM  Ada/370  Debugger.  It  duplicates  the  functions  of  the 
product  compiler  invocation  of  the  debugger.  The  debugger  works  only  for  programs 
written  in  Ada  and  compiled  by  the  IBM/Telesoft  Ada  compiler  for  MVS -targeted  code. 
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e.  Assembler  Language  input  to  the  assembler  Is  called  a  source  module. 
Asseidtler  translates  the  source  module  into  an  object  module.  The  object  module 
is  then  read  into  the  computer  and  processed  by  a  linkage  editor  or  loader.  The 
linkage  editor  prepares  a  program  for  execution  by  creating  a  load  module,  then 
storing  the  program  in  a  load  module  library.  Once  the  program  is  included  in  a 
permanent  load  module  library,  it  may  be  executed  without  assembling  and  link¬ 
editing. 

When  the  IBM  RISC  System/6000  tools  are  used,  all  source  code  and  outputs  of  that 
code  are  configuration  isanaged  on  the  3090  Job  Shop  via  SCLM.  The  term  self -host 
refers  to  code  that  is  both  developed  and  maintained  on  the  RISC  System/6000 
processors.  The  primary  RISC  System/6000-resident  software  development  tools  are: 

a.  Advanced  Interactive  Executive  (AIX)  Operating  System.  The  AIX  is  used  on 
the  RISC  System/6000  processor  to  allow  users  and  application  programs  to  interact 
with  RISC  System/6000  computers.  Users  can  directly  manage  files  on  a  disk,  start 
application  programs ,  and  print  files .  AIX  supports  C ,  Assembler ,  and  Ada 
programming  languages.  AIX  comes  with  two  full-screen  editors,  as  well  as  a 
symbolic  debugger  that  is  used  for  debugging  programs. 

b.  Ada/6000  Compiler  (Self -HOST)  occupies  between  six  and  seven  megabytes 
(MB)  of  disk  space.  It  occupies  30  MB  if  users  Include  compiler  executables, 
support  files,  and  runtime  libraries.  The  Ada  compiler  can  be  used  under  both  AIX 
shell  programs,  sh  and  csh.  The  sh  program  is  the  default  shell  interpreter.  Csh 
is  a  more  advanced  shell  that  provides  command  line  recall  and  editing.  To 
establish  an  environment,  a  user  ustially  edits  the  shell  program  that  is  executed 
at  login.  These  shell  programs  are  contained  in  files  in  the  default  (login) 
directory.  The  files  are  named  profile  for  the  sh  shell  and  login  for  the  csh 
shell . 


c.  Symbolic  Debugger  For  AIX  Ada/6000  is  a  helpful  tool  for  correcting  errors 
in  an  Ada  program.  On  the  AIX  operating  system,  the  symbolic  debugger  may  be  used 
to  debug  programs  written  in  Ada,  C,  and  Assembler  language.  The  synibolic  debugger 
enables  users  to: 

1.  Debug  programs  at  either  the  source  language  or  asseinbler 
language  level. 

2.  Run  a  program  one  line  or  one  instruction  at  a  time. 

3.  Examine  the  source  text  using  simple  search  functions  or 
the  user ' s  own  editor . 

4.  Trace  execution  of  a  program  by  line,  instruction,  routine, 
or  variable. 

4. 1.6. 2. 1.4  Ada  Maintenance  Using  Rational  RIOOO. 

On  the  AAS  project,  the  Rational  processors  are  being  utilized  for  AAS  software 
development.  These  processors  were  obtained  with  the  intent  of  mitigating  risk 
associated  with  Ada  software  development.  The  Rational  Development  Environment 
is  designed  for  improving  the  overall  productivity  associated  with  developing  Ada 
software.  The  Rational  environment  has  three  main  capabilities: 
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«.  CoBBand  Line  Interface.  The  interface  to  the  envlronBent  for  issuing 
system  commands  is  presented  as  an  Ada  block.  Vithin  this  block,  it  is  possible 
to  write  detailed  Ada  programs  iising  any  Ada  construct.  The  most  common  use  of  the 
command  line  interface  is  to  invoke  the  Rational  environment  system  commands.  All 
Rational  commands  are  represented  as  Ada  subprograms  that  are  invoked  via 
the  "declare  block."  This  complete  tise  of  the  Ada  language  in  all  aspects  of  the 
environment  Increases  the  user's  awareness  and  knowledge  of  the  Ada  language. 

b.  Knowledge  Based  Editor.  The  task  of  developing  Ada  software  on  the 
Rational  is  greatly  enhanced  by  the  use  of  the  Rational  syntax  directed  editor. 

The  editor  can  perform  the  mundane  tasks  that  are  typically  left  to  the  user. 

Chores  such  as  insertion  of  redundant  keywords,  named  association  of  procedure 
call  parameters,  and  adjtistment  of  indentation  levels  are  a  few  of  the  items  that 
can  be  handled  automatically  by  the  editor. 

c.  Compilation  Facilities.  The  Rational  environment  provides  an  assortment 
of  facilities  for  compiling  Ada  units.  Within  the  Rational  editor,  syntax  and 
semantic  compilation  can  be  invoked  by  pressing  a  single  function  key.  The  most 
innovative  aspect  of  the  Rational  compilation  facility  is  Incremental  compilation. 
Rational  maintains  object  dependencies.  If  a  given  object  is  to  be  changed. 
Rational's  compilation  facilities  can  determine  the  dependent  objects  that  would  be 
affected.  This  allows  functions  such  as  editing  comments  specifications,  or  adding 
new  subprograms  to  package  specifications  to  be  performed,  without  requiring 
recompilation  of  the  dependent  units.  This  feature  alone  can  have  tremendous 
benefits  in  reducing  the  compilation  time  associated  with  developing  Ada  software. 

The  Rational  development  environment  is  a  viable  alternative  to  creating  new 
software  on  the  3090.  When  new  software  is  created,  the  supporting  software  would 
need  to  be  in  existence  on  the  Rational  processor  in  a  compiled  state.  For 
development  of  Ada  software  on  the  AAS  project,  using  Rational  processors  for  new 
development  of  large  software  modules  through  the  unit  test  phase  of  the  software 
is  very  essential.  This  requires  Ada  specifications  and  working  bodies  for  the 
supporting  common  software.  Unit  testing  on  the  Rational  processors  allow  the 
developer  to  make  use  of  the  Rational  facilities  to  verify  that  the  logic  paths 
within  the  software  are  correct. 

^■16-2.2 _ Cross  System  Product  (CSP). 

Cross  System  Product  (CSF)  is  a  fourth -generation- language  application  generator 
designed  to  Increase  programmer  productivity.  It  produces  applications  that  are 
portable  and  easy  to  maintain.  CSF  is  composed  of  two  products: 

a.  CSP/Appllcation  Development  (CSP/AD)  which  provides  complete  facilities 
for  pro^  ammers  to  define  and  generate  applications. 

b.  CSP/Application  Execution  (CSF/AE)  which  executes  the  generated  programs 
in  a  production  environment. 

The  CSF,  with  its  built-in  DB2  Interface,  is  used  in  the  implementation  of  the 
support  software  operating  in  the  AAS  Job  Shop.  Portions  of  CCAB,  ENVT,  and  SITE 
are  implemented  in  the  CSF  language. 
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The  Cross  System  Product  Programmers  Workbench  (CPW)  provides  a  complete  CSP 
developnent  environment  that  significantly  Improves  the  productivity  of  CSP 
application  developers.  The  CPW  provides  a  common  Interface  to  both  the  CSP/AD 
and  CSP/AE  products.  The  CPW  tools  allow  application  developers  to  Interact  with 
the  CSP/AD  and  the  CSP/AE  products  with  a  minimal  amount  of  system  knowledge.  Many 
of  the  CPW  tools  provide  an  Interface  to  CSP/AD  batch  commands,  which  allows  the 
Interactive  session  to  continue  while  CSP  processes  Jobs  In  the  background.  The 
CPW  tools  provide  functions  that  supplement  CSP.  such  as  preparing  applications  for 
execution  with  DB2. 

The  CPW  automates  many  CSP  system  administration  functions: 

a.  Creating,  moving,  and  deleting  Member  Source  Libraries  (MSLs)  and 
Application  Load  Files  (ALFs) . 

b.  Maintaining  MSLs  and  ALFs. 

c.  Managing  security  authorization  to  restricted  CPW  functions  and  restricted 
MSLs  and  ALFs. 

The  CPW  tools  can  operate  multiple  levels  of  products,  such  as  CSP  and  DB2,  and 
other  environment* specific  requirements,  such  as  supporting  multiple  DB2 
subsystems . 

There  are  three  methods  that  exist  to  test  a  CSP  application: 

a.  Write  and  immediately  test.  The  code  may  be  tested  after  the  application 
is  coded  using  CSP/AD. 

b.  Code,  generate,  and  test.  Generate  application,  translating  the  source 
Into  an  executable  module  stored  In  the  ALF.  Then  test  through  CSP/AD. 

c.  Generate  module  Into  ALF.  Code  under  CSP/AD.  Then  generate  using  the 
test  facility  under  CSP/AE. 

After  the  CSP  application  Is  built  and  tested,  the  CPW  promote  tool  is  used  to 
promote  the  application  up  the  hierarchical  levels. 

4.1.7  Documentation . 

The  documentation  maintenance  system  that  resides  on  the  AAS  Job  Shop,  combines  CAS 
products  with  AAS -developed  software  tools  and  panels  to  fonn  a  comprehensive 
procedure  for  managing  documents. 
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Docuoentation  changes  are  laanaged  using  the  ACI  process.  A  single  ACI  is  used  Co 
control  BodificaCions  to  AAS  documentation  across  multiple  system  releases.  With 
documentation,  the  unit  of  tracking  for  the  ACI  is  the  document. 

Whenever  possible,  CAS  is  used  to  develop  and  maintain  AAS  documentation.  IBM's 
design  stipulates  the  use  of  the  BookMasCer  CAS  product  as  the  word  processing 
language  to  produce  the  AAS  technical  manuals.  FAA  Documentation  maintainers 
(ACN-600)  plan  to  use  a  different  CAS  product.  Interleaf,  to  maintain  AAS 
documentation.  A  study  performed  by  ACN-600  found  Interleaf  to  be  more  compatible 
across  government  agencies  and  more  versatile  across  the  various  computer 
platforms.  ACN-600  plans  to  use  a  filter  to  convert  AAS  documentation  from 
Bookmaster  on  the  AAS  Job  Shop  to  Interleaf. 

i.1.8 _ Resource  Scheduling. 

In  order  to  assure  the  availability  of  resources  within  the  SSCC,  all  potential 
users  must  request  the  use  of  facility  equipment  and  support.  The  resource 
scheduling  CAS  product  provides  a  means  to  manage  resources  and  facilities,  and 
their  use.  It  provides  for  defining  laboratory  resources  and  scheduling  time  in 
the  laboratories.  Functions  performed  by  the  resource  scheduling  software  include; 


a.  Create  request 

b .  Modify  request 

c.  Browse  request 

d.  Delete  requests 

e.  Cancel  requests 

f.  Browse  facility  information 

g.  Browse  resource  information 

h.  Create  schedule  and  usage  reports 

I.  Maintain  facility  schedules 

J .  Maintain  facility  definitions 

ACN-600  is  responsible  for  coordinating  the  user  requests  and  the  management  of 
SSCC  resources.  ACN-600  will  use  the  resource  scheduler  information  and  reports  to 
accommodate  user  requests. 

The  resource  scheduling  software  is  accessible  by  selecting  the  Resource  Scheduling 
option  on  the  AAS  Administration  and  System  Support  Menu. 

4.1.9  Remote  Logon. 

The  site  support  maintenance  team  is  responsible  for  ensuring  that  the  AAS  system 
operates  correctly  and  that  all  related  hardware  components  and  software  systems 
are  operational.  To  achieve  this  goal,  the  site  support  personnel  must  establish 
and  control  the  environment;  recognize  and  report  problems;  test,  verify  and 
install  new  system  releases  and  hardware  equipment;  and  assist  in  the  update  of 
site  adaptation  data. 

To  support  field  problem  resolution,  AOS  personnel  have  the  capability  to  logon  to 
the  support  processor  at  each  field  site.  This  capability  enables  AOS  maintenance 
personnel  to  respond  quickly  to  critical  problems  by  accessing  relevant  data  at  the 
site  for  problem  analysis. 
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Since  the  source  version  of  the  software  and  adaptation  data  will  reside  at  the  Job 
Shop,  site  software  personnel  oust  interact  with  SSCC  personnel  and  Operational 
Field  Support  personnel  to  report  problems,  receive  logic  releases,  or  update  their 
adaptation  data.  If  communications  with  SSCC-1  are  lost,  the  ARTCC  will  have  the 
capability  to  perform  emergency  software  maintenance  autonomously. 

4.2  FACILITY  AND  SIMULATION  CONTROL  (F&SC)  OEERATIQNS. 

The  F&SC  subsystem,  which  encompasses  the  FCC  and  the  SAS,  provides  resources  for 
performing  the  following  major  functions: 

a.  Managing  site  configurations  of  the  SSF  for: 

1.  Software  modification  support 

2.  Hardware  modification  support 

3.  System  testing  and  verification  support 

b.  Monitoring  and  controlling  the  configuration  of  SSCC  resources 

c.  Initiating  simulation  scenarios 

Managing  site  configurations  involves  coordinating  with  the  requestor  (e.g., 
software/hardware  developers,  testers,  or  trainers)  to  determine  the  specific 
demands  for  the  SSF  as  well  as  physically  configuring  the  SSF  to  logically 
replicate  the  desired  field  site.  Coordination  includes  identifying  the  purpose 
of  the  request  and  scheduling  the  event.  To  physically  reconfigure  the  SSF,  the 
F&SC  operator  obtains  the  site  configuration  and  accesses  the  software  logic  and 
adaptation  data  from  the  Job  Shop  subsystem.  Via  the  FCC,  the  F&SC  operator 
transforms  the  SSF  into  a  logical  replication  of  the  desired  site.  Since  only  a 
limited  number  of  CCs  are  located  at  the  Technical  Center,  the  SSF  includes  a 
substantial  nun^er  of  CCS  which  may  be  included  in  the  SSF  configuration.  Upon 
completion  of  this  configuration,  the  SSF  is  ready  to  perform  the  requested 
simulation. 

The  FCC  performs  the  monitoring  and  controlling  of  the  configuration  of  the  SSCC 
resources.  This  is  discussed  in  detail  in  section  4.2.1. 

Simulation  scenarios  are  developed  and  stored  in  the  Job  Shop.  The  F&SC  operator 
retrieves  the  scenarios  from  the  Job  Shop  and  initiates  their  execution.  Once  the 
scenario  begins,  the  SSF  operates  similarly  to  the  site  until  the  simulation  is 
terminated  by  the  M&C  or  FCC  operator. 

4.2.1  Facility  Configuration  Control  (FCC). 

The  purpose  of  the  FCC  position  is  to  provide  a  centralized  location  from  which 
overall  SSF  scheduling,  configuration,  simulation,  and  testing  activities  can  be 
coordinated.  The  role  of  the  FCC  position  in  SSCC-1  is  synonymous  with  the  role 
of  the  M&C  position  in  ISSS.  Thus,  the  system  control  responsibilities  and  status 
data  display  requirements  for  the  FCC  are  similar  to  that  of  the  M&C  position. 
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Most  comands  and  displays  that  are  available  at  the  M&C  position  are  also 
available  at  the  FCC  console.  The  difference  is  that  the  FCC  position  does  not 
require  the  use  of  some  of  the  M&C  operational  commands,  therefore,  these  commands 
are  only  available  at  the  M&C  position.  Likewise,  there  are  specific  system 
support  commands  that  are  only  functional  from  the  FCC  console .  These  comsands 
are  only  available  at  the  FCC  position.  The  unique  FCC  commands  are  discussed  in 
detail  in  paragraph  4. 2. 1.2. 

The  FCC  operator  performs  the  following  major  functions: 

a.  Monitor  SSCC  resources 

b.  Support  SSF  site  configurations 

4^2. 1.1  Monitoring  and  Controlling  the  Confisuration  of  SSCC  Respurgeg. 

The  FCC  has  the  capability  to  view  many  different  aspects  of  the  configuration  of 
the  SSCC  resources.  Since  individual  operating  requirements  can  differ,  the  FCC 
operator  has  the  capability  to  arrange  selected  views  to  suit  his/her  individual 
configuration  needs.  The  following  are  the  core  group  of  proposed  views  for  the 
FCC: 


a.  FCC  System  Summary  View  -  Horizontal  (FSH)  and  FCC  System  Summary 
View  -  Vertical  (FSV) 

b.  FCC  Alert  Status  (FAS)  View 

c.  FCC  LCN  Status  (LCN)  View 

d.  FCC  Control  Room  (CRL)  View 

e.  FCC  Area  (ARL)  View 

f.  F&SC  Central  Processor  (CNP)  View 

g.  FCC  Facility  Alert  List  (FAL)  View 

h.  Message  Composition/Response  (MC/RS)  View 

i.  FCC  Key  Information  (FKI)  View 

j .  TIU-Processor  Relationships  (TPR)  View 

k.  FCC  Transfer  (TRN)  View 

The  three  FCC  System  Summary  views  are  the  FCC  System  Summary  view  -  Horizontal 
(FSH),  FCC  System  Summary  view  -  Vertical  (FSV),  and  FAS  view.  The  FSH  view  is 
designed  to  be  displayed  in  the  Auxiliary  Display  (AUX) .  The  FSV  view  is  designed 
for  use  with  other  M&C  views  on  the  Main  Display  Monitor  (MDM) .  The  FAS  view 
layout  is  identical  to  the  layout  of  the  FSH  view. 
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The  purpose  of  these  views  Is  to  present  a  sumary  of  the  resources  controlled  by 
the  FCC  In  order  to  facilitate  FCC  operator  identification  of  alerts  and  failures. 
When  alerts  occur,  the  sumary  icons  will  show  a  flashing  color  (red,  yellow,  etc.) 
to  reflect  where  the  alert  has  occurred.  When  the  alert  is  acknowledged,  the  FSH 
and  FSV  views  will  stop  reflecting  this  alert.  The  FAS  view  will  continue  to 
display  the  alert  condition  until  it  has  been  resolved.  This  is  the  only 
difference  between  the  FSH  and  FAS  views.  It  is  the  FCC  operator's  choice  to 
deteraine  which  system  sussiary  view  they  would  like  to  display. 

The  purpose  of  the  LCN  view  is  to  present,  in  one  view,  the  status  of  all  the 
bridges  and  rings  controlled  by  the  FCC.  This  view  was  designed  for  use  in  the 
MDM. 

The  purpose  of  the  FCC,  CRL,  and  ARL  views  is  to  provide  detailed  processor  level 
statxis  for  each  CC,  CCS,  Dynamic  Simulation  (DYSIM)  Pilot  Workstation,  Test 
Interface  Unit,  and  LCN  Interface  unit  in  the  system.  The  ARL  and  CEIL  views 
collect  the  processors  by  LCN  access  ring,  so  there  is  a  group  of  processor  icons 
in  the  AKL  and  CRL  views  for  each  LCN  access  ring  in  the  system. 

This  is  also  the  same  collection  criteria  for  the  summary  icons  on  the  FSH  and 
FAS  views,  so  there  is  a  one-to-one  mapping  between  processor  summary  icons  on 
the  FSH/FAS  and  a  group  of  processor  icons  in  the  ARL  and  CRL  views.  Therefore, 
the  FCC  operator  can  use  this  relationship  in  order  to  determine  which  ARL  or  CRL 
view  should  be  displayed  on  the  FCC  when  an  alert  is  being  signaled  by  the 
FSH/FAS  view.  The  only  difference  between  the  ARL  and  CRL  views  is  the  processor 
icons  in  the  ARL  view  display  application  software  status,  as  well  as  processor 
hardware  status. 

The  purpose  of  the  CNP  view  is  to  present  the  FCC  operator  with  the  status  of  the 
hardware  elements  for  the  9121  Central  Processor.  This  view  is  identical  to  the 
M&C  Central  Processor  view,  except  there  is  only  one  Central  Processor  shown  for 
the  F&SC. 

The  FCC  FAL  view  is  the  standard  M&C  FAL  view.  The  purpose  of  the  FAL  view  is  to 
alert  the  user  to  system  failures,  degradations,  recoveries,  performance 
exceptions,  processors  (which  are  ready  to  join  the  system),  and  command  response 
messages.  The  FAL  view  displays  only  the  primary  alerts  followed  by  the  secondary 
alerts . 

The  MC/RS  view  is  the  standard  M&C  MC/RS  view.  The  purpose  of  the  MC/RS  view  is  to 
give  the  operator  a  place  to  type  commands,  or  make  command  selections,  and  a  place 
to  display  command  completion  messages  and  NAS  acceptance  messages. 

The  purpose  of  the  FKI  view  is  to  display  summary  information  about  the  SSF.  This 
view  will  give  the  FCC  operator  a  summary  of  the  SSF  status,  the  system  release 
loaded,  access  ring  status,  and  M&C  position  information. 

The  purpose  of  the  TPR  view  is  to  show  the  relationship  between  the  rack-mounted 
CCSs,  and  the  TIU  that  is  attached  to  those  CCSs.  (One  TIU  and  up  to  four  CCSs  are 
mounted  together  in  the  same  rack.) 

The  purpose  of  the  TRN  view  is  to  give  the  FCC  operator  the  capability  to  easily 
select  any  other  available  FCC  or  M&C  view. 
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Each  of  the  i^ove  aentloned  views  will  assist  the  FCC  operator  in  all  aspects  of 
■onitoring  and  controlling  the  configuration  of  the  SSCC  resources.  The  FCC 
operator  can  sinply  use  the  TRN  view  to  configure  the  MDM  and  AUX  with  the  required 
views  to  assist  the  person  in  the  specific  monitoring  function. 

4. 2. 1.2 _ FCC  Support  of  Site  Logical  Replications. 

One  of  the  most  iisportant  tasks  of  the  FCC  position  is  to  provide  the  necessary 
support  for  the  preparation  phase  that  precedes  the  operation  of  an  SSF.  The 
"preparation  phase"  is  defined  here  as  the  set  of  coordinated  actions  and 
procedures,  executed  both  before  and  during  the  SSF  configuration  process,  which 
results  in  the  creation  of  the  required  user-specified  environment  capable  of  being 
transferred  to  the  SSF  M&C  position  for  further  system  initialization  activities. 

The  following  specific  FCC  commands  are  used  to  configure,  initiate,  support,  and 
terminate  a  SSF: 

a.  Reserve  Mimic 

b .  Configure  Mimic 

c.  Startup  M&C  Command 

d.  Termination  of  the  Mimic 

e .  Reset  Command 

f.  Start  FCC  SCM/BGS  Command 

The  following  is  a  description  of  each  of  these  commands,  along  with  a  description 
of  the  FCC  operator's  role: 

a.  Reserve  Mimic.  The  purpose  of  the  Reserve  Mimic  command  is  to  verify  that 
a  requested  configuration  can  be  supported  with  the  SSF  resources  available,  and  to 
hold  these  resources  until  directed  to  release  them. 

While  the  Reserve  Mimic  command  is  executing,  the  FCC  operator  is  given  reservation 
status  via  alert  message(s)  posted  on  the  FAL  view.  If  a  complete  configuration  is 
available,  the  resources  are  automatically  reserved  and  the  ARL,  CRL,  and  FAL  are 
updated  accordingly  showing  the  new  status.  The  resources  are  held  in  reserve 
until  a  Reset  or  Terminate  command  is  Issued. 

If  one  or  more  requested  resources  are  not  available,  a  message  is  posted  on  the 
FAL,  and  the  ARL  and  CRL  views  are  updated  to  reflect  that  status. 

If  the  complete  requested  resources  are  not  reservable,  the  operator  has  the  option 
to  accept  or  reject  the  limited  configuration.  The  FCC  operator  will  have  an 
overall  picture  of  the  incomplete  configuration  upon  which  to  base  their  decision. 
In  addition  to  messages  in  the  FAL  view,  the  operator  can  verify  details  in  the  ARL 
and  CRL  views.  If  the  FCC  operator  accepts  the  configuration,  by  entering  the 
Reserve  A(ccept)  command,  the  resources  will  be  reserved  for  the  SSF.  If  the  FCC 
operator  rejects  the  configuration,  the  system  defaults  to  its  initial  monitor 
status  and  resources  will  be  available  for  another  logical  replication. 

b.  Configure  Mimic.  The  purpose  of  the  Configure  Mimic  command  is  to  perform 
the  actual  resource  configuration  actions  on  the  SSF  resources.  If  the 
configuration  process  is  successful,  the  SSF  is  ready  to  start  the  SSF  via  the 
Mimic  Startup.  If  the  CCs  have  been  reserved  for  the  SSF,  the  appropriate 
adaptation  data  will  be  used  to  configure  it. 
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If  the  configuration  action  on  a  processor  or  ring  set  fails,  the  FCC  operator  will 
be  inforaed  via  a  message  in  the  FAL  view,  and  the  ARL  and  CRL  views  will  be 
updated  to  reflect  that  status.  The  operator  will  then  have  the  option  to  perform 
one  of  the  following: 

1.  Accept  the  configuration  without  the  processor  or  ring  set  by  entering 
the  Configure  Mimic  command  with  the  Accept  parameter. 

2.  Reject  the  configuration  and  start  recovery  actions  by  entering  the 
Configure  Mimic  command  with  the  "Reject"  parameter. 

When  all  actions  are  completed  successfully  or  when  the  software  has  completed 
configurations  with  acceptance  of  failed  or  unavailable  resources,  the  SSF  is 
considered  configured  and  the  FCC  operator  receives  a  system  message  in  the  FAL 
view. 

If  the  FCC  operator  chooses  to  cancel  the  process,  the  support  software  will 
attempt  to  deconfigure  all  resources  that  had  been  successfully  configured  before 
the  failure.  If  the  software  cannot  successfully  recover,  the  FCC  operator  may 
issue  M&C  commands  to  recover  FCC  resources,  and  a  Reset  command  to  initialize  the 
support  software.  The  support  software  would  then  be  capable  of  successfully 
executing  a  Reserve  Mimic  command  for  another  user/tester. 

c.  Start  M&C  Command.  The  purpose  of  the  Start  M&C  command  is  to  initiate 
the  independent  functioning  of  an  acceptably  configured  SSF.  This  command 
initiates  the  full  operation  of  the  SSF  M&C  or  an  M&C  group  so  that  the  SSF  may  be 
fully  controlled  from  its  M&C  console<s)  in  the  same  manner  as  in  a  field  facility. 

This  process  is  accomplished  by  starting  a  CC  in  the  SSF  configuration  as  the  SSF 
M&C,  and  deactivating  the  bridge  set  that  connects  the  F&SC  support  rings  to  the 
SSF  backbone  ring  set.  The  CC  designated  to  become  the  M&C  must  be  a  physical  CC. 
No  other  bridge  sets  in  the  SSF  are  affected  by  this  command. 

During  the  Start  M&C  command  process  the  software  will  generate  the  following 
commands : 


1.  Issue  a  Defer  Assign  request  to  a  CC  in  the  SSF  configuration  in  order 
to  direct  it  to  become  the  M&C  of  the  SSF. 

2.  Issue  a  request  to  warm-start  the  LGSM  of  the  designated  CC  in  order 
for  it  to  become  the  M&C. 

3.  Command  the  bridge  set  connecting  the  F&SC  support  rings  to  the  SSF 
backbone  LCN  to  inactive  mode. 

If  either  step  1  or  2  fails  in  this  process,  the  FCC  operator  can  issue  another 
Start  M&C  command  and  the  software  will  resume  where  it  had  previously  failed. 

After  the  software  completes  the  M&C  warm-start  and  deactivates  the  F&SC  bridge 
set,  it  will  send  a  startup  complete  message  to  the  FAL  view. 
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If  a  "renegade”  M&C  is  detected  as  starting  to  come  up,  there  will  be  a  ring 

failure  condition.  An  error  message  is  sent  to  the  FCC  operator,  via  the  Facility 

Alert  List,  to  "kill”  the  renegade  M&C.  Once  the  M&C  condition  is  corrected,  the 
FCC  operator  can  issue  a  Teminate  comaand  or  another  Start  M&C  comsand.  The  FCC 
operator  may  issue  a  Tenainate  or  Reset  command  if  the  Startup  command  does  not 
execute  properly. 

d.  Terminate  Mimic.  The  purpose  of  the  Terminate  Mimic  command  is  to 
deconfigure  the  hardware  resources  allocated  to  the  SSF,  leaving  it  in  a  state 
ready  to  accept  a  Reserve  Mimic  comaand  for  the  next  mimic.  The  following  events 
are  a  result  of  the  termination  command: 

1.  The  software  activates  the  F&SC  support  ring  bridge  set. 

2.  The  software  issues  commands  to  set  resources  in  the  SSF  to  diagnostic 

state.  The  FCC  regains  the  capability  to  obtain  and  display  resource  status  via 
the  ARL  and  CRL  views. 

3.  The  SSF  is  available  for  the  next  logical  replication. 

If  a  reconfiguration  action  on  a  processor  fails,  the  operator  is  notified  via  the 
Feedback  area  of  the  Message  Composition  (MC)  view.  Failures  may  be  handled  by  the 
FCC  operator  using  M&C  commands  executed  at  the  FCC,  after  the  software  has 
completed  its  attempts  at  disconflguring  all  resources. 

e.  Reset  Command.  Whenever  the  SSF  is  in  an  unknown  or  inde  ciminate  state, 
M&C  commands  may  be  issued  in  order  to  initialize  resources  for  another  logical 
replication.  At  that  point,  execution  of  the  Reset  Command  will  permit  the  FCC 
operator  to  issue  a  Reserve  Mimic  command  to  initiate  the  steps  necessary  to  start 
another  SSF. 

f.  Start  FCC  SCM/BGS  Command.  This  command  is  used  to  Initiate  the 
processing  of  SCM  or  BGS  software  at  the  FCC  console.  The  command  has  the  same 
functions  as  the  M&C  Start  SCM/BGS  command  with  one  critical  exception.  In  the 
SSCC-1,  the  FCC  console  has  the  responsibility  for  monitoring  and  controlling  the 
resources  on  both  the  LCN  and  the  BCN.  The  M&C  consoles  monitor  either  the  LCN  or 
the  BCN;  they  never  monitor  both  networks  simultaneously  at  a  site.  However, 
simultaneous  monitoring  of  these  networks  can  be  accomplished  on  the  FCC,  via  use 
of  this  command. 

4.2.2  Stand-Alone  Simulator  (SAS). 

The  SASs  provide  simulation  services  and  test  scenario  generation  for  the  SSFs. 

The  SASs  are  connected  to  the  F&SC  9121  processor  with  VM/ESA  running  on  one  of  the 

9121  partitions.  Dedicated  SAS  AUs  allow  tests  involving  simulations  to  be  run 
Independently  of  the  other  SSFs,  and  also  allows  both  SSFs  to  run  separate  tests 
involving  simulation  concurrently. 

The  SDR  software  runs  in  the  SAS.  The  SDR  aids  the  user  in  preparing  simulated 
input  to  NAS  from  adjacent  NAS  and  Automated  Radar  Terminal  System  (ARTS)  centers, 
without  knowledge  of  NAS  assigned  Computer  Identifications  (CIDs) .  This  simulated 
input  is  sent  to  NAS  over  an  Interfacility  Input  (INTI)/Interfacility  Output  (INTO) 

adapter  set.  In  addition  to  providing  data  from  a  simulated  adjacent  NAS  or  ARTS 

center,  SDR  prints  diagnostic  listings  and  input  message  listings. 
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The  SOR  software  will  be  aodlfled  for  SSCC-1  because  BOARC  is  not  capable  of 
handling  input  channel  data  rates  greater  than  2400  bits  per  second  (bps).  In 
order  to  acconaodate  this  llaitatlon,  SDR  will  be  changed  to  allow  for  the  SAS 
radar  data  output  for  each  siaulated  radar  site  to  be  distributed  across  three 
separate  and  unique  channels.  This  will  effectively  reduce  the  SAS  AU  radar  output 
data  rate,  causing  the  PANRI  and  EOARC  input  data  rates  to  drop  from  7200  bps  to 
2400  bps.  To  accoaplish  this,  SDR  will  be  modified  to  aap  the  siaulated  radar  site 
data  to  the  physical  devices  (SAS  AU  serial  ports)  based  on  the  logical  device 
number,  rather  than  based  on  ^e  radar  site  Identifier. 

4.3  SYSTEM  SUPPORT  FACILITY  (SSE)  QPERATIQHS. 

The  SSF  operates  as  a  logical  replication  of  a  particular  field  site.  It 
includes  the  site's  software  logic  and  Sector  Suite  adaptation  data,  the  hardware 
configuration,  and  interfaces.  The  objective  of  the  SSF  is  to  increase  the 
effectiveness  of  testing  and  training  by  systems  support.  , 

Testing  Includes  both  hardware  and  software  components  and  ranges  from  the 
resolution  of  field  problems  to  the  examination  of  full  system  releases. 

Functional,  as  well  as  predeploynent ,  testing  can  be  conducted.  Emrloying  actual 
adaptation  data,  quantitative  measurements  against : realistic  envirorrsents  can  be 
achieved.  Since  ^e  SSF  can  replicate  any  field  site, t complete  and  ccmprehenslve 
system  testing  of  any  or  all  sites  (Including  evaluation  of  site  certification 
cutover  procedures)  can  be  performed.  Data  from  System]‘Analysis  Recorder  (SAR) 
files  can  be  extracted  to  create  newrseenario  events  which  may  serve  to  precisely 
tailor  the  scenario  to  a  particular  ARTCC.  The  anticipated  outgrowth  is  quality 
isqirovement;  the  ability  to  distribute  a  system  that  was  actually  tested  against  t 
site  replica. 

Pools  of  CCs  and  CCCs  axe  available  on  the  LCN  for  connection  to  the  HSFs. 
Sxifficient  resources  are  available  to  replicate  the  largest  ISSS  site  or  configure 
two  distinct  ISSS  sites  simultaneously. 

4.3.1  Logical  Replication  of  a  Sit. 

The  logical  replication  of  a  site  can  be  used  to  support  the  follow.(  -g  major 
functions : 

a.  Testing  of  baseline  and  delta  system  releases 

b.  Testing  of  hardware  and  software  field  problems 

c.  Training  of  personnel  (support  and  controller) 

4. 3. 1.1  Testing  of  Baseline  and  Delta  System  Releases. 

After  the  FCC  operator  has  configured  the  SSF  to  logically  replicate  the  desired 
site,  with  the  new  baseline  or  delta  system  release,  the  operator  ma;;  thcr:  begin 
testing  the  new  release.  AT  support  personnel  can  run  their  standard  equ:ument  r-. 
environmental  simulation  tools,  on  the  new  release  in  the  specified  operational 
environment,  to  completely  test  the  new  release. 
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A.Siul.2 Testing  of  Hardware  and  Software  Field  Problems. 

With  the  ability  to  replicate  a  site,  the  field  support  personnel  are  better  able 
to  provide  a  more  thorough  analysis  of  field  problems.  Since  the  simulation 
scenarios  are  repeatable,  regression  testing  can  be  readily  conducted  to  determine 
whether  proposed  solutions  will  have  an  Impact  on  the  problem.  Through  the  use  of 
the  site  replication,  with  extensive  regression  testing  of  the  solution,  the  field 
support  personnel  can  be  confident  that  their  fix  will  have  no  unforeseen  Impact  on 
the  specific  operational  site. 


?■  SYSTEM  MAIFTEy/tf^gE. 


The  SSCC-1  System  Maintenance  encompasses  hardware,  operational  and  support,  and 
firmware  maintenance.  Based  on  the  SSCC-1  centralized  maintenance  concept,  AA.S 
hardware  and  software  at  the  ARTCC  will  be  maintained  using  SSCC-1  resources. 

The  Advanced  Automation  Program  (AAP)  Office  has  provided  contractor  maintenance 
for  the  first  year  after  equipment  acceptance  at  each  ARTCC.  During  this  year, 
each  ARTCC  will  evaluate  their  readiness  to  assume  total  stalntenance  responsibility 
for  hardware  components.  If  necessary,  each  ARTCC  may  extend  contracted  hardware 
maintenance  on  a  year-to-year  basis,  not  to  exceed  9  years  of  maintenance. 
Operational  software  will  continue  to  be  contractor-maintained,  centrally  at  the 
Technical  Center,  under  AOS's  control  and  guidance.  Adaptation  data  will  always  be 
maintained  by  the  ARTCC.  Hardware  and  software  certification  will  be  performed  by 
AOS  at  the  Technical  Center  and  FAA  personnel  at  the  ARTCC. 

The  critical  and  complex  nature  of  the  AAS  dictates  the  need  for  a  rigid  set  of 
maintenance  requirements.  Failures  In  the  system  could  have  a  considerable 
negative  Impact  on  air  traffic  activity.  An  effective  solution  Is  required  when 
the  FAA  Is  faced  with  an  unexpected  adverse  situation.  Based  on  the  need  for 
constant  system  availability  and  the  critical  operational  environment  of  AAS,  the 
following  maintenance  requirements  apply  to  the  AAS  system: 

a.  The  FAA  work  force  must  be  capable  of  ensuring  that  no  compromise  of 
safety,  reliability,  or  availability  exists  throughout  the  AAS  life  cycle. 


b.  FAA  personnel  must  have  the  technical  expertise  to  manage  and  control  the 
AAS  segments'  equipment  configurations,  to  direct  restoration  and  to  certify  the 
system  or  Its  elements  as  appropriate. 

c.  Should  the  loss  of  contractor  support  for  mission-critical  systems  occur, 
the  FAA  must  be  capable  of  assuming  full  responsibility  for  the  required  system 
maintenance  using  FAA  resources. 

d.  FAA  maintenance  control  centers  must  be  staffed  by  FAA  personnel  to  ensure 
immediate  response  to  ATC  needs . 

e.  System  restoration  capability  and  support  resources  must  be  available 
continually  for  mission-critical  elements  of  the  system. 

f.  Second- level  engineering  support  must  be  available  continually  for 
mission- critical  elements  of  the  system. 
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Maintenance  plans  are  structured  to  support  high  system  availability.  Support 
analyses  have  been  correlated  to  the  design  of  the  system  to  guide  in  the  planning, 
development,  and  implementation  of  logistic  elements  of  support  such  as  handbooks, 
support  equipment  tools,  and  distribution  of  documentation.  These  analyses  and 
plans  have  also  addressed  the  design,  development,  and  production  of  the  hardware 
and  microcode  modifications  required  to  improve  system  perfoinnance ,  correct 
problems,  and  expand  system  capabilities. 


Hardware  maintenance  is  conducted  on  two  levels  in  accordance  with  FAA  Order 
6000.30.  In  the  SSCC-1  time  frame,  IBM  will  perform  first-level  maintenance 
involving  the  removal  and  replacement  of  defective  or  obsolete  lowest  replaceable 
units  (LRUs) .  IBM  will  also  be  responsible  for  sending  the  removed  articles  to  the 
appropriate  second- level  maintenance  facility.  All  other  maintenance  actions  are 
the  responsibility  of  the  second- level  maintenance  facility,  either  the  FAA 
Logistics  Center  or  the  FAA  Technical  Center,  whichever  is  appropriate.  Other  than 
required  for  on-site  maintenance,  interaction  with  vendors  is  accomplished  through 
the  second-level  maintenance  facility.  Table  5.1-1  lists  the  matrix  for  structured 
hardware  and  firmware  maintenance.  The  first  year  of  maintenance  will  be  full  IBM 
maintenance  support  per  the  contract  to  include  all  spare  parts.  Uhen  structured 
maintenance  starts,  the  designated  elements  (FAA  or  IBM)  will  be  responsible  for 
spare  parts  for  those  items  they  are  maintaining  per  the  following  matrix: 


TABLE  5.1-1.  MATRIX  FOR  STRUCTURED  HARDWARE  AND  FIRMWARE  MAINTENANCE 


Item/Unlt  Name 

1st  Level 
Responsibility 

2nd  Level 
Responsibility 

CCs 

FAA 

FAA 

CTS 

FAA 

FAA 

ESI 

FAA 

FAA 

CENTRAL  CLUSTER 

IBM 

IBM 

HOST 

IBM 

IBM 

LCN 

FAA 

FAA 

LIU 

FAA 

FAA 

BCN 

FAA 

FAA 

When  a  hardware  problem  occurs,  the  first  task  is  to  reconfigure  the  system  in 
order  to  isolate  the  problem  area,  ensuring  that  the  system  recovers  into  a 
functionally  sound  mode  of  operation.  Once  the  system  has  recovered,  the  goal  of 
hardware  problem  identification  is  to  identify  the  specific  LRU  that  has  caused  the 
problem,  and  initiate  the  repair  activity  associated  with  that  element. 


The  diagnosis  of  hardware  problens  may  involve  actions  that  alter  the  software 
state  of  a  processor.  Prior  to  taking  such  actions,  steps  are  taken  to  preserve  as 
much  software  status  data  as  possible.  This  information  is  needed  in  cases  where 
the  hardware  is  not  the  root  cause  of  the  trouble. 

The  SSCC  has  maintenance  features  that  complement  system  support  activities  to  help 
achieve  the  goals  of  the  maintenance  concept.  These  features  significantly  reduce 
overall  repair  time  by  providing  technicians  with  the  ability  to  diagnose  a 
malfunction  rapidly,  identify  the  failed  unit,  and  replace  it  quickly.  These 
maintenance  features  include: 

a.  Internal,  on-line  diagnostics  that  identify  a  failed  unit. 

b.  Simplified  removal  and  replacement  maintenance  methods  which  streamline 
the  process  for  restoring  equipment  to  an  operable  condition. 

c.  Built-in  test  equipment  to  aid  in  fault  isolation. 

d.  Remote  monitoring  control  and  diagnostic  capabilities  to  test  and  detect 
imminent  failures. 

IxXlI _ Hardware  Maintenance  Levels. 

As  mentioned  in  section  5.1,  there  are  two  levels  of  hardware  maintenance,  first 
and  second.  First-level  maintenance  encompasses  all  maintenance  activities  which 
take  place  at  the  field  site.  The  AOS  organization  accomplishes  the  field  site 
maintenance  effort  as  soon  as  it  is  practical  to  assume  these  tasks  from  IBM. 

First- level  maintenance  usually  consists  of  periodic  checks  of  equipment, 
monitoring  of  performance,  inspection,  cleaning,  servicing,  and  adjusting.  It  also 
includes  troubleshooting  and  testing  in  accordance  with  the  equipment  manuals.  The 
AOS  organization  is  the  single  point  of  contact  for  all  maintenance  actions  at  the 
ARTCC. 

Second- level  maintenance  support  consists  of  those  maintenance  actions  performed  at 
the  FAA  Logistics  Center  or  the  FAA  Technical  Center.  The  FAA  Logistics  Center  is 
responsible  for  depot  level  maintenance,  ensuring  sufficient  spares  are  procured 
and  maintained  to  support  first-level  requirements.  This  includes  ensuring 
operational  facilities  receive  replacement  parts  in  a  timely  manner. 

For  second- level  maintenance,  reporting  procedures  concerning  hardware  problems 
remains  the  same  regardless  of  the  type  of  maintenance  action  being  performed. 

Air  Traffic  (AT)  and  Airways  Facilities  (AF)  organizations  at  the  ARTCC  will  use 
the  ACI  to  report  technical  problems.  The  ACI  process  ensures  compatibility  to 
existing  FAA  systems .  Problems  reported  to  the  Technical  Center  are  handled  in 
accordance  with  the  AOS  and  SSCC  Operations  Concepts,  and  prioritized  based  on 
criteria  contained  therein. 

The  AOS  organization  at  the  Technical  Center  is  responsible  for  developing  and 
distributing  the  certification  and  maintenance  procedures  for  the  system  and 
controlling  the  maintenance  handbook.  This  group  generates  necessary  Site 
Technical  Bulletins  (STBs). 
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ACN-500  Is  responsible  for  receiving  and  implementing  modifications  to  the  SSCC-1 
platform.  As  such,  they  analyze  the  changes,  develop  modifications  to  existing 
hardware  to  accommodate  the  changes,  and,  with  approval  of  the  appropriate  CM 
group,  implement  the  changes. 

_ Hardware  Maintenance  Types. 

There  are  three  types  of  hardware  maintenance.  Corrective  Maintenance,  Preventive 
Maintenance,  and  Perfective  Maintenance.  These  maintenance  types  apply  to  both 
system  and  siibsystem  hardware  elements. 

Corrective  maintenance  is  any  action  performed  to  restore  a  failed  system  to  an 
operational  state.  For  first-level  maintenance,  this  includes  analyzing  error 
conditions,  removing  and  replacing  failed  LRUs  and  sending  them  to  a  second- level 
maintenance  facility  when  required.  While  under  contractor  maintenance,  first- 
level  corrective  siaintenance  is  controlled  by  FAA  personnel.  Thereafter,  it  will 
be  both  controlled  and  performed  by  the  FAA. 

Second- level  corrective  maintenance  includes  analyzing  error  conditions  and 
accomplishing  repairs  to  failed  components,  and  also  ensuring  sufficient 
replacements  are  available  to  satisfy  both  local  and  site  requirements. 

Second- level  corrective  maintenance  is  controlled  and  performed  by  the 
Logistics  Center  and  the  Technical  Center,  as  appropriate.  The  Logistics 
Center  ensures  repairs  are  made  to  failed  LRUs  while  ensuring  sufficient 
replacement  LRUs  are  available  to  satisfy  requirements. 

Preventive  maintenance  encompasses  all  actions  that  are  performed  to  retain  the 
SSCC-1  platform  in  an  acceptable  operational  condition.  First-level  preventive 
maintenance  is  routine  scheduled  maintenance  designed  to  preserve  the  equipment  or 
reduce  the  chance  of  failure.  The  responsibilities  of  the  FAA  and  contractors  for 
first-level  corrective  maintenance  also  apply  to  first-level  preventive 
maintenance . 

Second- level  preventive  maintenance  includes  inspection  and  calibration  activities 
to  preserve  the  equipment  and  to  reduce  the  change  of  failure.  The  AOS 
organization  is  responsible  for  the  generation  and  maintenance  of  the  appropriate 
Maintenance  Technical  Handbook  which  identifies  all  preventive  maintenance  actions. 
The  contractor  is  responsible  for  providing  technical  documentation  to  define 
recommended  preventive  maintenance.  Including  procedures  and  timing. 

Perfective  maintenance  covers  those  maintenance  actions  resulting  in  improved 
performance  or  maintainability  of  the  system.  Perfective  maintenance  actions  may 
be  initiated  by  the  FAA,  maintenance  contractors  or  vendors,  but  are  only  performed 
under  the  guidelines  of  FAA  CM. 

For  first-level  perfective  maintenance,  the  FAA  is  responsible  for  controlling  the 
approval  and  implementation  of  all  perfective  maintenance  efforts  as  they  relate  to 
SSCC-1  and  ISSS. 


65 


For  second* level  perfective  maintenance,  AOS  generated  Electronic  Equipment 
Modifications  (EEMs)  and  STBs  provide  the  FAA  with  authority  to  accomplish 
perfective  maintenance  actions.  If  a  contractor  Is  the  Initiator  of  a  perfective 
maintenance  action,  AOS  personnel  provide  guidance  and  recoimsendatlons  concerning 
operational  Impacts  and  suitability.  The  contractor  provides  any  engineering 
change  Information  required  for  AOS  to  complete  the  EEMs  and  STBs  associated  with 
the  maintenance  tasks. 

5.2  CENTRALIZED  SOFTWARE  MAINTENANCE  CONCEPT. 

The  centralized  software  maintenance  concept  designates  SSCC-1  as  the  focal  point 
for  software  and  adaptation  database  maintenance.  The  centralized  approach  differs 
significantly  from  the  former  approach  to  NAS  software  maintenance  where  Individual 
ARTCCs  owned  both  their  operational  software  and  their  adaptation  data. 

Software  maintenance  Is  conducted  on  two  levels  In  accordance  with  the  Policy  for 
Maintenance  of  the  NAS  FAA  Order  6000.30.  ARTCCs  perform  first -level  maintenance 
Involving  conduct  of  local  adaptation  maintenance,  problem  Identification  and 
Isolation,  downloading,  testing,  and  cutover  of  new  releases.  This  effort  holds 
true  for  all  releases  down  to  the  Functional  Group  (FG)  or  Operational  Unit  (OU) . 
All  other  maintenance  actions  are  the  responsibility  of  the  second- level 
maintenance  facility,  the  Technical  Center.  The  AOS  organization  at  the  Technical 
Center  will  be  responsible  for  all  field  site  maintenance  problems.  Vendor 
interaction  Is  the  same  as  for  hardware  maintenance. 

The  concept  of  operations  presented  here  Is  based  on  a  cooperative  working 
relationship  between  the  Individual  ARTCCs  and  the  Technical  Center.  Under  this 
relationship,  the  ARTCC  gathers  data  on  the  circumstances  .surrounding  a  software 
problem  occurrence  and  develops  a  preliminary  assessment  based  on  this  data.  The 
level  of  Involvement  of  the  Technical  Center  In  this  process  is  determined  by  the 
severity  of  the  Impact  that  the  problem  presents.  For  minor  problems,  ARTCC- 
generated  problem  data  Is  passed  to  the  Technical  Center  for  review  by  AOS  and 
final  resolution.  This  procedure  Is  part  of  the  normal  ACI  process. 

For  more  severe  problems,  the  AOS  may  use  the  ARTCC  remote  access  facilities  to 
participate  In  the  ARTCC-level  problem  determination  process.  ARTCCs  will  have  the 
capability  of  performing  emergency  software  maintenance  If  communications  are  lost 
with  the  Technical  Center.  For  some  problems,  the  site  data  is  collected  and  used 
to  attempt  the  reconstruction  of  problems  using  the  SSF  at  the  Technical  Center. 

The  SSF  Is  designed  to  provide  a  logical  replica  of  the  operational  site.  The  SSF 
Is  loaded  with  ARTCC  software,  adaptation  data,  and  problem- related  data.  The 
software  development  environment  provides  additional  capability  to  analyze  software 
problems.  For  persistent  problem  situations,  the  AOS  can  dispatch  a 
troubleshooting  team  to  the  ARTCC. 

Software  elements  include  CAS  products,  AAS-developed  application  code  and 
individual  operational  site  adaptation  data.  When  a  software  element  failure 
occurs,  the  first  task  is  to  reconfigure  the  system  and  recover  to  a  functionally 
sound  mode  of  operation.  The  goal  of  software  problem  identification  is  to 
identify  the  failed  software  component.  Sufficient  data  should  be  gathered  to 
generate  an  ACI. 
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There  are  approxlaately  84  CAS  products  in  the  ISSS/SSCC-1  segnents  of  the  AAS. 
Along  with  these  products,  there  is  contract- developed  software  that  is  categorized 
as  operational  site  real- tine  software,  and  operational  site  background  support 
software.  There  is  also  SSCC-1  Job  Shop  support  software. 

Software  naintenance  is  viewed  as  a  continuation  of  the  AAS  software  development 
process.  The  procedures  used  for  software  maintenance  are  similar  to  those  used  to 
develop  the  AAS.  The  toolset,  development  environment,  and  CM  techniques  are 
carried  forward  from  AAS  development  to  the  maintenance  program. 

5.l2 J _ Software  Maintenance  Levels. 

As  mentioned  in  section  5.2,  there  are  two  levels  of  software  maintenance. 

First- level  maintenance  includes  all  maintenance  activities  which  take  place  at 
the  field  site.  AOS  will  assume  life-cycle  maintenance  support  responsibilities 
after  the  first  year  after  Contractor  Acceptance  Inspection  (CAI).  Reporting 
procedures  concerning  software  for  first- level  maintenance  are  the  same  as  those 
for  second- level  hardware  maintenance. 

Second- level  siaintenance  is  composed  of  those  maintenance  actions  performed  at  the 
Technical  Center.  These  activities  encompass  correcting  defective  software 
releases.  Introducing  changes  and  modified  code  to  accommodate  perfective  changes 
and  those  changes  necessary  to  accommodate  site  adaptation  requirements  as  a  result 
of  changing  site  configurations.  This  includes  ensuring  first- level  facilities 
receive  modified  code,  new  releases,  or  delta  releases  in  a  timely  manner.  An 
allocated  concept  of  FAA  and  contractor  support  has  been  determined  to  be  the  most 
beneficial  to  FAA  long-term  goals.  Reporting  procedures  are  the  sane  as  for 
first-level  software  maintenance. 

AOS  is  responsible  for  developing  and  distributing  the  certification  and 
maintenance  procedures  for  the  system.  AOS  personnel  are  also  responsible  for 
receiving  and  Implementing  CAS  modifications.  As  such,  they  analyze  changes, 
develop  modifications  to  existing  software  to  accommodate  the  changes,  and  obtain 
approval  from  appropriate  CM  groups  for  implementation  of  the  changes.  This  group 
generates  necessary  Site  Program  Bulletins  (SPBs).  The  changes  are  tested  first  at 
the  Technical  Center  and  key  sites,  and  then  released  to  field  sites. 

ACN-400  is  responsible  for  developing,  testing,  and  implementing  modifications  to 
SSCC-1  developed  code  and  CAS  products.  ACN-400  will  coordinate  any  changes  that 
affect  field- site  resident  support  software  with  the  AOS  organization. 

5.2.2  Software  Maintenance  Types. 

SSCC-1  provides  resources  for  three  different  types  of  software  maintenance: 
Corrective  Maintenance,  Perfective  Maintenance,  and  Adaptive  Maintenance. 

Corrective  maintenance  includes  those  maintenance  actions  required  to  correct 
errors  in  system  performance.  For  first-level  corrective  maintenance,  this 
includes  analyzing  error  conditions,  removing  and  reloading  failed  software 
and  firmware,  and  providing  information  necessary  for  problem  resolution  to 
second-level  maintenance  facility  when  required. 
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Flrst'level  FAA  responsibilities  for  corrective  maintenance  fall  into  two 
categories:  problem  identification,  which  is  described  in  section  5.2.4,  and 
problem  correction.  Site  personnel  perform  all  actions  required  for  problem 
identification,  while  AOS  performs  actions  required  for  problem  resolution.  This 
covers  data  collection  and  analysis,  providing  information  to  appropriate  personnel 
at  the  Technical  Center,  initiating  an  ACI,  and  ultimately  performing  local  test 
and  verification  of  the  corrections  downloaded  from  the  Technical  Center.  The 
contractor  provides  technical  assistance  for  the  extent  of  the  service  contract. 

Second- level  corrective  maintenance  includes  analyzing  error  conditions,  and,  based 
upon  available  information,  developing  corrections  to  existing  software  releases. 
These  corrections  can  be  provided  in  the  form  of  a  full  system  release  or  a  smaller 
delta  release.  If  the  problem  cannot  be  resolved  immediately,  the  second- level 
facility  provides  a  workaround  solution  based  on  input  from  the  first- level 
facility. 

For  second- level  corrective  maintenance,  AOS  is  responsible  for  managing  the 
software  correction  process  and  providing  operational  guidance  and  interpretation 
to  the  contractor  performing  the  software  modifications.  They  also  design  and 
conduct  the  testing  effort  at  the  Technical  Center  to  ensure  the  solution  is 
operationally  suitable  and  solves  the  problem.  The  FAA  is  also  responsible  for  all 
interaction  with  the  CAS  vendors  to  resolve  CAS  associated  problems.  The 
contractor  is  responsible  for  developing  and  performing  all  changes  to  software 
required  for  correcting  deficiencies  in  the  existing  release.  This  includes 
conducting  necessary  testing  to  ensure  the  system  does  not  fail.  The  exact  manner 
for  accomplishing  this  task  is  included  in  the  AOS  and  SSCC  Operations  Concepts. 

Perfective  maintenance  refers  to  the  type  of  software  maintenance  that  the  SSCC-1 
performs  to  eliminate  inefficiencies,  enhance  performance  and/or  Improve 
maintainability.  Perfective  maintenance  actions  may  be  initiated  by  the  FAA, 
maintenance  contractors,  or  vendors. 

For  first-level  perfective  maintenance,  AOS  is  responsible  for  performing  local 
test  and  verification  of  new  releases.  This  includes  the  need  to  perform  those 
necessary  certification  steps  before  bringing  the  release  on-line  to  be 
operational.  The  contractor  is  responsible  for  Informing  the  local  FAA  personnel 
of  expected  changes  arising  from  perfective  maintenance  efforts  undertaken  by  the 
contractor  or  it  subcontractors.  They  also  assist  with  local  verification  and 
provide  information  on  any  operational  impacts. 

Second- level  perfective  maintenance  responsibilities  for  the  FAA  include  providing 
the  contractor  and  other  vendors  information  to  be  used  in  performing  perfective 
maintenance.  In  those  Instances  where  the  contractor  is  the  initiator  of  the 
perfective  maintenance  action,  the  Technical  Center  personnel  provide  guidance  and 
recommendations  concerning  operational  impacts  and  suitability.  The  contractor  is 
responsible  for  developing  the  necessary  code  to  integrate  perfective  changes  into 
a  new  release  and  for  developing  the  necessary  test  actions  to  ensure  the  newly 
developed  code  performs  to  required  standards. 

Adaptive  maintenance  refers  to  the  type  of  software  maintenance  that  is  performed 
using  the  SSCC-1  to  keep  up  with  changes  in  data  and  processing  environments.  For 
first  level  adaptive  maintenance,  this  includes  those  maintenance  actions  required 
to  adapt  releases  to  local  conditions ,  which  includes  modifications  required  for 
both  short-  and  long-term  solutions. 
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Field  site  personnel  are  coapletely  responsible  for  site  adaptation,  collecting 
Infomatlon,  selecting  the  local  adaptation  database,  downloading,  testing, 
cutover,  and  verification  of  new  releases.  Each  site  Is  responsible  for 
Instituting  Its  own  procedures  and  assigning  responsibility  for  acconpllshlng  this 
maintenance  action  In  compliance  with  appropriate  FAA  orders.  The  contractor  has 
no  first-level  responsibilities  to  perform  adaptive  maintenance. 

Second- level  adaptive  maintenance  Includes  all  efforts  to  adapt  the  designed  system 
to  changing  national  and  local  environments.  It  Includes  those  actions  necessary 
to  obtain  the  data  for  national  data  releases,  and  to  conduct  liaison  with  other 
government  agencies  and  organizations,  as  well  as  those  In  the  aviation  Industry  to 
obtain  the  required  information. 

AOS  collects  the  necessary  Information  to  develop  and  release  the  necessary 
adaptation  data  at  the  national  level  In  accordance  with  FAA  Orders  and 
Regulations.  The  contractor  Is  responsible  for  Incorporating  the  Information  Into 
new  system  releases  In  a  timely  manner. 

5.3  FIRMWARE  MAINTENANCE. 

SSCC-1  firmware  maintenance  will  follow  a  centralized  maintenance  concept  Identical 
to  that  of  hardware  and  software  maintenance.  The  second-level  support 
organization  (FAA  Technical  Center)  will  develop,  test,  document,  and  distribute 
all  changes  to  firmware  for  SSCC-1  and  ISSS.  FAA  Logistics  Center  will  provide 
support  by  providing  Erasable  Programmable  Read-Only  Memoiry  (EPROM)  bum  in.  IBM 
will  support  the  maintenance  of  firmware  during  the  contractor  maintenance  period. 

5.4  PROBLEM  IDENTIFICATION. 

Problem  Identification  falls  under  the  problem  Identification  category  of 
first-level  software  corrective  maintenance.  It  is  the  process  of  establishing 
the  source  of  an  observed  system  problem  or  failure.  The  primary  focus  of  problem 
Identification  Is  the  engineering  aspect  relative  to  the  tasks  that  are  performed 
at  the  M&C  position. 

Problem  Identification  begins  when  a  degradation  or  failure  Is  observed. 

Information  and  diagnostic  capabilities  provided  by  system  monitoring  are  used  to 
help  Isolate  the  source  of  the  problem.  The  objective  is  to  establish  a  baseline 
for  hardware  repair,  software  restoration,  and  the  preparation  of  an  ACI  whenever 
applicable . 

Each  of  the  maintenance  manuals  for  the  AAS  Includes  problem  Identification 
procedures  associated  with  hardware  and  software  components,  developed  specifically 
for  the  AAS  application.  Commercial  handbooks  supply  similar  maintenance 
information  for  all  COTS  hardware  elements  and  CAS  products  that  are  used  in  the 
AAS. 

Problem  identification  involves  a  combination  of  engineering,  technique,  and 
reporting  disciplines.  Engineering  involves  design  of  the  system  and  establishment 
of  fundamental  processes  that  are  based  on  anticipated  problems;  therefore, 
engineering  is  a  series  of  causes  and  effects. 
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The  technique  or  approach  to  problem  identification  involves  the  appropriate  and 
effective  use  of  the  tools  provided  by  engineering.  The  day-to-day  application  of 
problem  identification  methods  is  often  influenced  by  accumulated  experience. 
Operators  develop  an  understanding  of  the  system  that  allows  them  to  resolve 
problems  without  consulting  the  uintenance  manual.  This  situation  is  a  reflection 
of  the  fact  that  problem  identification  is  usually  an  effect-cause  process. 
Maintenance  personnel  must  sort  through  a  number  of  different,  occasionally 
contradictory,  clues  in  order  to  determine  the  cause  of  a  problem. 

The  staffing  levels,  policies,  procedures,  and  paper  work  associated  with  system 
problems  involve  problem  reporting  and  tracking.  One  of  the  tasks  of  problem 
identification  CM  is  to  ensure  that  the  lessons -learned  of  day-to-day  experience 
are  collected  and  incoxi>orated  into  the  problem  identification  engineering  effort. 
This  is  accomplished  by  tracking  reported  problems  and  keeping  a  record  (ACI)  of 
the  symptoms  of  and  solutions  to  the  problem.  This  record  may  prove  helpful  in 
providing  solutions  to  problems  that  have  been  previously  reported,  and  this 
information  may  reduce  the  time  needed  to  restore  Che  system. 

1^  .^TEM  PROBLEM  RESOLUTION  METHODS. 

System  problems  result  from  the  distributed  nature  of  the  AAS  architecture. 
Trouble-free  operation  of  the  system  requires  that  various  software  and  hardware 
elements  linked  by  LCNs  support  system  processing  threads.  System  performance 
problems  fall  into  this  category.  System  problems  are  sometimes  complicated  in 
nature.  Initially,  they  often  appear  to  be  either  hardware  or  software  problems. 

In  these  cases,  the  goal  of  system  problem  identification  is  to  identify  the  system 
configuration  that  creates  the  problem. 

Resolving  system  problems  requires  an  ability  Co  reconstruct  the  sequence  of  events 
and  processing  flows  that  lead  to  the  problem.  These  reconstruction  efforts  may 
require  the  coordinated  use  of  several  software  and  hardware  problem  Identification 
tools . 


Inteimal  System  Analysis  Recording  (SAR)  data  can  be  used  to  gather  data  on  the 
data  processing  flow  of  a  selected  process.  System  operators  can  activate  SAR 
gates  associated  with  the  collection  of  system  debugging  information.  This  data  is 
used  to  determine  the  nature  of  Che  processing  errors  that  are  causing  the  problem 
condition. 

External  SAR  of  selected  messages  support  the  reconstruction  of  the  sequence  of 
events  that  led  to  the  problem.  The  AAS  distributed  processing  architecture  is 
based  on  individual  software  elements  exchanging  data  via  Service  Requests  (SRs) 
and  Service  Request  Responses  (SRRs).  The  SRs  and  SRRs  are  labeled  and  time- 
tagged  to  support  the  calculation  of  system  response  times.  This  time- tagging 
information  also  allows  system  specialists  to  reconstruct  system  data  flows. 

The  SAR  performance  data  can  play  a  role  in  the  detection  of  system  problems. 
Response  time  and  device  utilization  information  can  be  used  to  detect  system 
processing  bottlenecks.  This  Information  can  be  generated  by  Data  Reduction  and 
Analysis  (DR&A)  processing  of  SAR  performance  data. 


The  prlnary  users  of  the  SSCC-1  are:  AOS  Operational  Support  Services,  the  ACN 
Service,  and  field  site  personnel.  The  SSCC-1  platfom  is  also  available  for  use 
by  other  FAA  organizations. 

i.L_OPERATIO«AL  SUPPORT  SERVICE  USERS. 

AOS  personnel  are  functionally  linked  to  ARTCC  facilities  and  operations. 

Based  at  the  Technical  Center,  AOS  develops  and  controls  operational  system 
modifications,  analyzes  and  corrects  system-wide  or  national  problems,  and  assists 
ARTCC  staff  in  solving  difficult  site  problems.  AOS  has  direct  access  to  SSCC 
resident  operational  software  and  to  national  and  site  specific  adaptation 
databases.  AOS  will  have  the  requisite  skills  and  resources  to  fulfill  maintenance 
responsibilities  to  support  the  fielded  ISSS. 

The  following  outlines  major  responsibilities  of  the  AOS  organization  relevant  to 
the  use  of  the  SSCC  for  providing  support  to  the  field  sites.  This  list  represents 
only  a  subset  of  responsibilities  of  the  AOS  organization. 

a.  Support  the  field  with  problem  diagnosis. 

b.  Maintain  operational  software,  documentation,  and  CAS  products 
at  the  site. 

c.  Maintain  site -resident  hardware. 

d.  Maintain  national  adaptation  databases. 

6.2  ACN  SERVICE. 

ACN  personnel  support  and  maintain  the  hardware,  software,  and  functional 
capabilities  of  SSCC-1  including  COTS  and  CAS  products.  Within  the  ACN 
organization  is  the  Build  and  Control  (B&C)  team,  whose  primary  function  is 
SSCC  CM.  The  SCLM  Administrator  is  an  active  member  of  this  team.  ACN 
responsibilities  include,  but  are  not  limited  to: 

a.  Providing  SSCC-1  software  problem  diagnosis,  software  updates, 
and  software  maintenance. 

b.  Providing  SSCC-1  hardware  problem  diagnosis,  hardware  engineering 
support,  and  hardware  maintenance. 

c.  Ensuring  the  availability  and  proper  configuration  of  SSCC-1 
equipment . 

d.  Testing  all  new  and  upgraded  SSCC-1  system-related  software  and 
hardware . 


e.  Operations  of  the  AAS  Job  Shop,  F&SC  Subsystem,  and  the  SSFs. 


f.  Configuring  SSF  equlpnent  to  replicate  and  emulate  precisely 
defined  conditions  at  ARTCCs. 

g.  Maintaining  CM  and  library  management. 

ARTCC  users  of  SSCC-1  have  access  to  Job  Shop  resources  through  direct  terminal 
logon.  Although  they  may  be  physically  separated  by  many  miles  from  the  Technical 
Center,  they  will  be  functionally  integrated  into  the  SSCC-1  operations. 

6.3  FIELD  SITE  PERSONNEL. 

The  field  site  personnel  ensure  that  all  AAS-related  hardware  and  software 
components  are  operational  at  the  ARTCC.  The  field  site  personnel  must  establish 
and  control  the  ARTCC  software  environment  and  diagnose  and  report  any  problems  to 
the  Technical  Center,  via  the  ACl  process.  Through  the  SSCC-1  remote  logon 
capability,  site  adaptation  data  specialists  update  their  o%m  local  adaptation 
data.  Site  software  personnel  create,  receive,  test,  verify,  and  install  new 
system  releases.  If  communications  with  the  SSCC-1  platform  are  lost,  field  site 
personnel  have  the  capability  to  perform  emergency  software  maintenance. 


7.  TRAINING. 


The  SSCC-1  platform  will  be  used  to  provide  training  to  FAA  personnel  and  support 
contractors  on  SSCC-1  functions  and  the  application  of  those  functions  to 
operational  areas. 

SSCC-1  training  will  be  developed  for  operations,  software  maintenance,  hardware 
maintenance,  and  system  management  support  personnel.  IBM  will  develop  the  SSCC-1 
training  curricula  in  accordance  with  the  Contract  Training  Program  FAA- STD- 028 
and  the  approved  AAS  contract  modifications.  Following  initial  contractor 
presentations  of  each  training  course,  life  cycle  training  will  become  the 
responsibility  of  the  FAA.  Only  transition  training  will  be  provided  to  field 
site  users;  long-term  development  training  is  the  responsibility  of  the  FAA. 

Technical  Center  personnel  will  receive  training  specifically  designed  fox  the 
SSCC-1  platform,  and  will  be  provided  by  IBM  according  to  CDRL  TR08.  To  implement 
Technical  Center  requirements,  training  will  be  provided  to  Technical  Center  Test 
and  Evaluation  (T&E)  and  AOS  personnel,  through  contractor-delivered  training 
services,  engineering  support  services,  and  applicable  segments  of  training 
developed  for  site  personnel. 


AAP 

AAS 

ACCC 

ACF 

ACl 

ACN-300 

AD 

ADP 

AE 

AF 

AIX 

ALF 

AOS 

APSE 

ARL 

ARTCC 

ARTS 

ASF 

ASM 

ASMH 

AT 

ATC 

ATCT 

AU 

AUX 

BCN 

B&C 

bps 

CAI 

CAS 

CC 

CCAB 

CCB 

CCD 

CCP 

CCS 

CDC 

CDRL 

CHI 

CID 

CIU 

CLIST 

COMPOOL 

COTS 

CM 

CMS 

CNP 

CPW 


Advanced  Automation  Program  Office 
Advanced  Automation  System 
Area  Control  Computer  Complex 
Advanced  Comwmication  Facility 
AAS  Change  Instrument 
Advanced  Automation  Division 
Application  Development 
Automated  Data  Processing 
Application  Execution 

National  Automation  Field  Support  Division 
Advanced  Interactive  Executive  Operating  System 
Application  Load  File 

National  Automation  Engineering  and  Field  Support  Division 
Ada  Programming  Support  Environment 
FCC  Area  View 

Air  Route  Traffic  Control  Center 
Automated  Radar  Terminal  System 
Alternate  Support  Facility 

National  Autonation  Engineering  Field  Support  Division, 
Assembler  H 
Assembler  H 
Air  Traffic 
Air  Traffic  Control 
Air  Traffic  Control  Tower 
Adapter  Unit 
Auxiliary  Display 
Backup  Communications  Network 
Build  and  Control 
bits  per  second 

Contractor  Acceptance  Inspection 
Commercially  Available  Software 
Common  Console 

Change  Control  and  Build  (CSCI) 

Configuration  Control  Board 
Configuration  Control  Decisions 
Common  Console  Processor 
Common  Console  Simulator 
Computer  Display  Channel 
Contract  Data  Requirements  List 
Computer  Human  Interface 
NAS  Computer  Identification 
Computer  Interface  Unit 
Common  List 
Common  Pool 

Commercial  Off-The-Shelf 
Configuration  Management 
Conversational  Monitor  System 
F&SC  Central  Processor  View 
CSP  Programmers  Workbench 
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CR 

CRL 

CS 

CSCl 

CSP 

CXSS 

DASD 

DB2 

DCC 

DCT 

DEV 

DF 

DFHSM 

DFP 

DFSORT 

DG 

DID 

DISP 

D&R 

DR&A 

DR&P 

DSF 

DSS 

DXT 

DYSIM 

ECP 

EDARC 

EEM 

ENVT 

EPROM 

ESI 

FAA 

FAL 

F&SC 

FAS 

FCC 

FG 

FKI 

FRACAS 

FSH 

FSP 

FSV 

FTP 

GFE 

GFI 

GFP 

GPI/0 

HCS 

HOL 

HOLC 

HPO 

IBM 


Change  Request 

FCC  Control  Rooo  View 

Central  Support 

Conputer  Software  Configuration  Item 

Cross  System  Product 

Common  System  Services  (CSCI) 

Direct  Access  Storage  Device 
Data  Base  2  application 
Display  Channel  Complex 
Detached  Console  Training 

Developmental  Integration  level  of  the  SCLM  hierarchy 
Data  Facility 

DF  Hierarchical  Storage  Manager 
DF  Product 
DF  Sort 

Display  Generator 
Data  Item  Description 
Display  Processing  (CSCI) 

Diagnostics  and  Repair 

Data  Reduction  and  Analysis 

Display  Recording  and  Playback 

Device  Support  Facility 

Data  Set  Services 

Data  Extract 

Dynamic  Simulation 

Engineering  Change  Proposal 

Enhanced  Direct  Access  Radar  ChaT.n'=‘l 

Electronic  Equipment  Modifications 

Environment  Data  Collection  (CSCI) 

Erasable  Programmable  Read  Only  Memory 

EDARC  System  Interface 

Federal  Aviation  Administration 

Facility  Alert  List  View 

Facility  and  Simulation  Control 

FCC  Alert  Status  View 

Facility  Configuration  Console 

Functional  Group 

FCC  Key  Information 

Failure  Reporting  Analysis  and  Corrective  Action  System 

FCC  System  Summary  View  -  Horizontal 

Flight  Strip  Printer 

FCC  System  Summary  View  -  Vertical 

File  Transfer  Program 

Government  Furnished  Equipment 

Government  Furnished  Information 

Government  Furnished  Property 

General  Purpose  Input/Output 

HOST  Computer  System 

High  Order  Language 

HOST  On-Line  Certification 

High  Performance  Option 

International  Business  Machines 
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ICA  Interfacility  Communications  Adapter 

ID  Identification 

INT  Integration  test  level  of  the  SCLM  hierarchy 

INTI  Interfacility  Input 

INTO  Interfacility  Output 

IP  Internet  Protocol 

ISPF  Interactive  System  Productivity  Facility 

ISSS  Initial  Sector  Suite  System 

IWS  Intelligent  Workstation 

JCL  Job  Control.  Language 

KCP  Keyboard  Communication  Processor 

LAN  Local  Area  Network 

LCN  Local  Communications  Network 

LIU  Local  Communication  Network  Interface  Unit,  Local  Area  Network 

Interface  Unit 

LRU  Lowest  Replaceable  Unit 

LSSS  Laboratory  Signal  Switching  System 

MB  megabyte 

M&C  Monitor  and  Control  Position 

HC  Maintenance  Console 

MC/RS  Message  Composition/Response  View 

MDM  Maintenance  Diagnostic  Monitor 

ME  Maintenance  Engineering 

MMI  Man-Machine  Interface 

MS  Modem  Splitter 

MSL  Member  Source  Library 

MTSS  MMI  Training  Support  Software  (CSCl) 

MVS/XA  Multiple  Virtual  Storage/Extended  Architecture 

NAR  NAS  Action  Request 

NAS  National  Airspace  System 

NASM  NAS  Modifications  for  ISSS  (CSCI) 

NCF  Network  Compilation  Facility 

NCF  NAS  Change  Proposals 

NFSG  National  Automation  Field  Support  Division 

OPC  Operations  Planning  and  Control 

ORD  Operational  Readiness  Demonstration 

OU  Operational  Unit 

PAMRI  Peripheral  Adapter  Module  Replacement  Item 

PDF  Program  Development  Facility 

PR/SM  Processor  Resource/Systems  Manager 

PS  Personal  System 

PSF  PAMRI  Services  Facility 

PTR  Problem/Trouble  Report 

PVL  Plan  View  Display 

F-/M  Virtual  Machine  Passthru 

RAAP  Recording  Analysis  and  Playback  (CSCI) 

RACF  Resource  Access  Control  Facility 

RCM  Radar  Controls  Multiplexer 

RDDU  Radar  Data  Distribution  Unit 

RDF  ROC  Data  Processor 

REL  Release/formal  test  level  of  the  SCLM  hierarchy 

REXX  ISPF  language/SCLM  Requirements  file 


RFSP 

RISC 

RMF 

ROC 

RSCS 

RTR 

SAR 

SAS 

SCLM 

SD 

SDR 

SDSF 

SIMF 

SITE 

SLOC 

SLS 

SMP/E 

SPB 

SPSS-X 

SR 

SRR 

SSCC 

SSF 

SSMS 

SSP 

STB 

TAAS 

T&E 

TBS 

TBD 

TCCC 

TCP/IP 

TIU 

TLCS 

TPR 

TRN 

TSO 

UDS 

VDD 

vm/esa 

VTAM 

XA 


Replmcement  Flight  Strip  Printers 

Reduced  Instruction  Set  Computer 

Resource  Measurement  Facility 

Refresh  Output  Controller 

Remote  Spooling  Communication  System 

Release  Tracking  Record 

System  Analysis  Recorder 

Stand-Alone  Simulator 

Software  Configuration  Library  Manager 

Software  Development 

Simulation  Driver 

System  Display  and  Search  Facility 
Simulation  Facility  (CSCI) 

Site  Data  Collection  (CSCI) 

Source  Lines  of  Code 
System  Level  Specification 
System  Modification  Program/Extended 
Site  Program  Bulletin 

Statistical  Package  for  the  Social  Sciences 

Status  Request 

Status  Request  Response 

System  Support  Computer  Complex 

System  Support  Facility 

Support  Software  Mimic  Suite 

System  Support  Programs 

Site  Technical  Bulletin 

Terminal  Advanced  Automation  System 

Test  and  Evaluation 

To  be  supplied 

To  be  determined 

Tower  Control  Computer  Complex 

Transmission  Control  Protocol/Intemet  Protocol 

Test  Interface  Unit 

Tape  Library  Control  System 

TIU  Processor  Relationships  View 

FCC  Transfer  View 

Time  Sharing  Option 

Universal  Data  Set 

Version  Description  Document 

Virtual  Machine/Extended  System  Architecture 

Virtvial  Telecommunication  Access  Method 

Extended  Architecture 


APPENDIX  A 

THE  TEN- STEP  AAS  CHANGE  INSTRUMENT  (ACI)  LIFE  CYCLE 


FAA  Order  1800. 8F  defines  policy,  delegates  authority,  and  assigns  responsibility 
for  ensuring  conpllance  with  all  National  Airspace  System  (NAS)  Configuration 
Management  (CM)  requirements.  This  ten-step  ACI  Life  Cycle  will  compliment  the 
operational  support  phase  requirements  described  In  that  Order. 

The  first  step  In  maintaining  or  developing  an  enhancement  to  the  Advanced 
Automated  System  (AAS)  Is  to  formally  Identify  the  problem  or  change  by  opening  an 
ACI.  Currently,  HOST  Computer  System  (HCS)  changes  and  problems  are  maintained 
using  the  INFO  Management  System.  This  INFO  Management  System  will  be  merged  with 
the  AAS  INFO  Family.  The  ACIs  will  be  used  to  track  all  modifications  to  the  AAS 
and  HCS.  Users  will  utilize  the  Change  Tracking  function  of  the  Operational  and 
Support  software  to  track  all  operational  system  problems  and  changes. 

Users  create  new  ACIs  by  entering  basic  Information  Into  the  database  through 
Interactive  panels.  Once  an  ACI  entry  Is  created.  It  Is  assigned  an  unique  number 
which  Is  used  for  tracking  the  ACI  and  for  referencing  It  In  the  future. 

Information  contained  In  the  ACI  may  be  added  or  changed  during  this  process. 

When  a  problem  Is  detected  or  a  change  Is  proposed  at  an  Air  Route  Traffic  Control 
Center  (ARTCC) ,  the  controller  fills  out  a  NAS  Action  Request  (NAR)  form,  as 
currently  performed.  The  NAR  Is  submitted  to  the  site  management  team  who 
determines  the  criticality  of  the  problem  or  the  necessity  of  the  change.  If  the 
site  management  team  decides  that  the  problem  must  be  fixed  or  the  change  should  be 
Implemented,  then  It  Is  assigned  to  the  NAS  Automation  Office.  The  NAS  Automation 
Office  personnel  will  be  respon.alble  for  opening  an  ACI  for  the  problem  or  change. 

When  a  problem  is  detected  or  a  change  Is  proposed  for  System  Support  Computer 
Complex  (SSCC)  system  components,  the  Federal  Aviation  Administration  (FAA) 
Technical  Center  personnel,  who  detected  the  problem  or  proposed  the  change  logs  on 
to  the  Job  Shop,  opens  an  ACI,  and  follows  the  life  cycle  for  the  ACI  outlined 
below. 

An  ACI  can  pass  through  ten  different  stages.  In  order  to  represent  the  status  of 
an  ACI  within  a  life  cycle  stage,  a  secondary  field  called  status  modifier  Is  used. 
The  status  modifier  represents  a  course  of  action  within  a  given  ACI  phase.  For 
example,  after  an  ACI  Is  opened.  It  may  be  accepted,  rejected,  or  held.  Accept, 
Reject,  and  Hold  are  status  modifiers.  The  combination  of  the  status  name  and  the 
status  modifier  determines  the  current  status  of  the  ACI  and  the  next  action 
performed  In  the  life  cycle. 

Some  status  modifiers  have  associated  disposition  values  which  further  explain  the 
status  modifier.  A  disposition  value  Is  a  reason  for  the  course  of  action.  For 
example.  If  an  ACI  was  opened  and  then  rejected  because  an  ACI  had  already  been 
opened  for  that  problem,  the  disposition  value  may  be  duplicate.  Status  modifiers 
and  dispositions  vary  according  to  whether  the  ACI  Is  a  Problem  ACI  or  a  Change 
ACI. 

The  Ten- Step  ACI  Life  Cycle  Is  outlined  in  table  A-1.  Figure  A-1,  ACI  Life  Cycle 
Statuses,  shows  the  relationship  between  each  life  cycle  status. 


A-1 


TABLE  A-1  TEN-STEP  ACI  LIFE  CYCLE 


Step 

Statxis 

Status  Modifier 

Description 

1 

OPEN 

Hold 

goto  SCREEN 

2 

SCREEN 

Pass 

goto  ASSIGN 

Re  j  ect 

goto  VERIFY 

3 

ASSIGN 

Section 

FAA  section  manager 

Active 

goto  RESOLVE 

Reassign 

goto  SCREEN 

Hold 

await  assignment 

4 

RESOLVE 

Change 

goto  BUILD 

Re  j  ect 

goto  VERIFY 

Ncbulld 

goto  TEST  or  VERIFY 

Hold 

wait 

Patch 

goto  BUILD 

5 

BUILD 

Request 

FAA  activity 

Pass 

goto  TEST 

Fail 

return  to  ASSIGN 

6 

TEST 

Pass 

goto  TRANSMIT  or 
INTEGRAT 

Fall 

return  to  ASSIGN 

Notest 

goto  TRANSMIT  or 
INTEGRAT 

Hold 

wait 

7 

TRANSMIT 

No  Status 

Modifiers 

8 

INTEGRAT 

Request 

FAA  activity 

Pass 

goto  VERIFY 

Fail 

return  to  ASSIGN 

9 

VERIFY 

Pass 

goto  CLOSE 

Fail 

return  to  SCREEN  or 
ASSIGN 

Hold 

wait 

10 

CLOSE 

Shipped 

Noship 

Reject 

Input  SPB  Number 

Hold 

AOS  uses 
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A.l  STEP  STATUS:  OPEN. 


The  following  paragraphs  describe  the  Ten-Step  Life  Cycle  of  an  ACI.  Differences 
between  Problem  ACIs  and  Change  ACIs  are  noted. 

Any  authorized  Technical  Center  or  ARTCC  personnel  may  open  an  ACI  by  logging  on  to 
the  AAS  Job  Shop.  When  an  ACI  Is  opened,  the  status  Is  OPEN  and  the  status 
modifier  Is  automatically  set  to  HOLD. 

An  ACI  must  Indicate  that  adaptation  data  Is  affected  to  allow  the  user  to  collect 
adaptation  data  for  that  ACI  via  the  Data  Collection  option.  The  adaptation  data 
Indicator  Is  set  on  the  Affected  Areas  Indicator  panel  of  the  AAS  ATC  Operational 
Support  and  Change  Tracking  support  software. 

4x1.1 _ Status  Modifier:  Hold. 

During  the  "OPEN,  Hold"  stage,  the  user  Is  prompted  to  provide  the  following 
Information  for  a  Problem  ACI: 

a.  Title  of  ACI 

b .  Originator  name 

c.  Originator  phone  number 

d.  Originator  organization 

e .  Origination  location 

f.  Date  occurred 

g.  Time  occurred 

h.  Segment  (l.e.,  SSCC-l) 

I.  General  ACI  type  (enter  a  code  for  the  severity  of  the  problem) 

J .  Formal  problem  (Y/N) 

k.  Date  the  fix  Is  Required 

l.  Reason  for  required  date 

m.  List  of  keywords  describing  problem  symptoms 

n.  Mode  of  operation  (the  mode  of  the  system  at  the  time  of  the  problem) 

o .  System  ID 

p .  Related  ACI 

q.  Problem  priority 

r.  Workaroui.d  available  (Y/N) 

s.  Status  modifier  (this  Is  automatically  set  to  HOLD) 

t.  Disposition 

The  Information  for  a  Change  ACI  Is  somewhat  different.  The  panel  prompts  the  user 
to  Input  the  following  Items; 

a.  Title  of  ACI 

b .  Originator  name 

c .  Origination  location 

d.  Originator  phone  number 

e.  Originator  organization 

f.  Change  class  (identifies  the  type  of  CR  the  ACI  is  written  to) 

g.  General  ACI  type  (en^er  a  code  for  the  severity  of  the  change) 

h.  Status  modifier  (this  is  automatically  set  to  HOLD) 

i.  Disposition 
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J .  List  of  keywords  describing  the  change 

k.  CR  nuaber 

l.  Date  of  CR  nuaber 

a.  Specification  Change  Notice  (SCN)/Docuaent  Change  Notice  (DCN)  nuaber 

n.  SCN/DCN  date 

o .  Change  priority 

p .  Baseline 

q.  Significant  category 

r.  Preliainary  (Y/N) 

Once  the  ACl  has  been  opened  and  all  known  information  for  the  problem/change  has 
been  entered,  the  originator  files  the  ACl  into  the  database  by  selecting  the  "file 
record"  option  from  the  panel.  The  INFO/Problem  Management  System  will 
automatically  assign  the  next  available  ACl  number  to  the  ACl  just  filed  into  the 
database.  This  number  identifies  the  ACl  and  is  used  to  track  its  progress  through 
the  ACl  life  cycle.  The  ACl  is  now  ready  for  screening.  The  screening  (Step  #2) 
life  cycle  phase  begins  with  the  ACl  status  at  "OPEN,  HOLD." 

A.2__STEP  #2>  STATUS:  SCREEN. 

During  this  phase,  the  ACl  origination  data  is  reviewed  to  determine  the  validity 
of  the  problem  or  the  criticality  of  the  change.  Screening  is  accomplished  on  a 
regularly  scheduled  basis  by  a  screening  team  made  up  of  at  least  one 
representative  from  each  of  the  functional  areas;  l.e.,  AOS,  ACN,  and  Field 
representatives.  This  team  will  review  all  new  problems/changes  which  are  in  the 
open  status  to  ensure  the  ACl  information  is  accurate  and  complete. 

When  an  ACl  is  opened  and  screened,  it  is  determined  whether  or  not  that  ACl 
affects  a  logic  release.  If  it  does,  a  Release  Tracking  Record  (RTR)  is  created 
for  that  ACl.  An  RTR  tracks  one  ACl  in  one  logic  release.  If  the  ACl  affects  more 

than  one  release,  an  RTR  must  be  created  for  each  release  in  which  that  ACl  is 

implemented. 

The  status  of  an  RTR  follows  the  same  life  cycle  as  an  ACl,  however,  the  status  of 
the  RTR  is  Independent  of  the  ACl.  For  example,  an  RTR  may  pass  through  the 
RESOLVE,  BUILD,  TEST,  and  INTEGRAT(E)  phases  tdille  the  base  ACl  remains  at  the 
SCREEN  phase  until  the  RTR  is  closed. 

When  the  status  of  the  ACl  has  been  decided,  the  status  modifier  is  updated  to 
reflect  these  results. 

A. 2.1  Status  Modifier:  Pass. 

If  the  ACl  is  approved,  the  status  modifier  is  updated  to  "SCREEN,  Pass."  The  ACl 

is  moved  from  the  SCREEN  to  the  ASSIGN  (Step  #3)  phase  of  its  life  cycle. 

A. 2. 2  Status  Modifier:  Reject. 


If  the  ACl  is  rejected,  the  status  modifier  is  updated  to  "SCREEN,  Reject,"  and  a 
disposition  reason  is  documented  as  follows: 


Rejection 

Disposition 

Disposition  Reason 

Nodata 

The  Information  provided  is  inadequate. 

Duplicate 

The  proposed  ACI  is  a  duplicate  of  an  existing  ACI. 

Usererror 

The  user  submitted  an  error  or  an  invalid  condition. 

The  ACI  statxis  is  moved  to  the  "VERIFY"  (Step  #9)  phase  of  its  life  cycle  in  order 
that  the  disposition  can  be  discussed  with  the  originator. 

A. 3  STEP  43>  STATUS:  ASSIGN. 

When  the  ACI  has  accepted  the  Configuration  Control  Board  (CCB)  and  assigns  the 
problem/change  to  an  organization  for  resolution.  Problem  priority  and  required 
fix  date  are  key  parameters  used  in  the  ASSIGN  step. 

A. 3.1  Status  Modifier:  Section. 

The  Control  Board  assigns  the  ACI  to  the  appropriate  resolving  organization.  While 
the  section  manager  of  that  organization  is  in  the  process  of  assigning  the  ACI  to 
an  analyst  for  resolution,  the  status  modifier  is  set  to  "ASSIGN,  Section."  The 
manager  provides  a  projected  release  availability  date  as  part  of  the  ASSIGN 
process . 

When  the  resolution  organization  for  the  ACI  has  been  selected,  the  status  modifier 
is  updated  to  reflect  the  decision. 

A .  3 . 2  Status  Modifier:-  Active . 

When  the  ACI  has  been  assigned,  the  stat\xs  modifier  becomes  "ASSIGN,  Active."  The 
section  manager  completes  the  Software  Target  Release  entry  for  production  control. 

Upon  becoming  active,  the  ACI  status  is  updated  to  RESOLVE  (Step  #4)  phase  of  its 
life  cycle. 

A. 3. 3  Status  Modifier:  Reassign. 

If  the  section  manager  determines  that  the  problem  or  proposed  change  is  out  of  the 
scope  of  their  area,  the  status  modifier  is  updated  to  "ASSIGN,  Reassign."  The  ACI 
status  returns  to  SCREEN  (Step  //2)  phase  of  its  life  cycle. 

A. 3 .4  Status  Modifier:  Hold. 

If  the  problem  or  change  does  not  have  a  required  "fix"  date  for  resolution,  the 
status  modifier  is  updated  to  "ASSIGN,  Hold"  until  the  ACI  is  assigned  to  a 
specific  logic  release.  When  the  ACI  is  assigned  to  a  logic  release,  the  status 
modifier  returns  to  "ASSIGN,  Section." 
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The  assigned  resolution  organization  studies  the  problem  or  proposed  change  and 
decides  vdiether  or  not  the  problem  requires  a  fix  or  the  change  needs  to  be 
implemented.  If  a  modification  is  required,  the  resolution  organization  National 
Autoiaation  Engineering  and  Field  Support  Division  ((AOS)  for  operational  software 
modifications)  decides  how  the  problem  will  be  fixed  or  how  the  change  will  be 
Implemented. 


Change  processing  for  the  operational  system  entails  the  processing  of  case  files 
and  NAS  Change  Proposals  (NCP) .  The  proposed  changes  are  reviewed  by  pertinent 
personnel  and  approved/disapproved  at  the  Maintenance  Engineering  (ME)  or  Air 
Traffic  (AT)  CCSs.  Decisions  are  documented  in  a  Configuration  Control  Decision 
(CCD).  A  CCD  must  be  obtained  to  complete  the  RESOLVE  (Step  ^4)  phase  of  the  ACI 
life  cycle. 


A.4.1 _ Status  Modifier:  Change. 


If  the  suggested  correction  or  update  involves  a  change  to  source  code 
software  build,  the  status  modifier  is  set  to  "RESOLVE,  Change."  This 
modifier  typically  refers  to  a  Problem  ACI  as  opposed  to  a  Change  ACI. 
code  changes  are  configuration  managed  through  the  logic  release  plan. 
Logic  Update  Procedures,  provides  details  on  the  logic  release  plan. 


requiring  a 
status 
All  source 
Appendix  C, 


The  ACI  status  is  updated  to  BUILD  (Step  #5)  phase  of  its  life  cycle,  with  a  status 
modifier  of  Request. 


A. 4. 2  Status  Modifier:  Reject. 

If  the  assigned  organization  is  unable  to  make  the  required  change,  the  status 
modifier  is  set  to  "RESOLVE,  Reject."  This  condition  may  be  caused  by  a  ntunber  of 
disposition  reasons.  For  example; 

a.  a  duplicate  ACI  which  was  not  identified  previously 

b.  an  ACI  which  does  not  identify  a  problem 

c.  an  ACI  with  insufficient  Information 

d.  a  change  to  documentation  only 

If  the  ACI  is  missing  information  or  if  the  ACI  is  rejected  altogether,  the  status 
returns  to  the  VERIFY  (Step  //9)  phase  of  its  life  cycle  in  order  that  the 
originator  can  fill  in  the  information  and  review  the  ACI. 

A.4.3  Status  Modifier:  Nobulld. 

If  the  proposed  modification  does  not  affect  software,  as  in  the  case  of  a  change 
to  adaptation  data,  the  status  modifier  is  set  to  "RESOLVE,  Nobuild."  This  status 
modifier  typically  refers  to  a  Change  ACI  as  opposed  to  a  Problem  ACI . 

If  the  solution  needs  to  be  tested,  the  status  is  updated  to  TEST  (Step  #6). 

If  the  solution  does  not  need  to  be  tested,  the  status  is  updated  to  VERIFY 
(Step  m. 
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If  the  further  eval\iatlon  of  the  resolution  or  modification  is  required,  the  status 
modifier  is  set  to  "RESOLVE,  Hold."  The  resolution  organization  may  elect  to  hold 
the  resolution  or  modification  until  a  subsequent  system  release  is  created.  When 
the  ACl  has  been  resolved,  the  status  modifier  is  updated  to  reflect  this  decision. 

Management  concurrence  should  be  obtained  to  complete  the  RESOLVE  phase. 

_ Status  Modifier:  Patch. 

New  patches  are  not  developed  for  ISSS;  however,  patches  that  have  not  been 
incorporated  into  the  baseline  operational  system  are  still  maintained  in  the 
National  Patch  Library  and  the  local  patch  libraries.  These  libraries  will  exist 
until  the  replacement  of  the  HOST  Computer  System.  Software  developers  will  still 
have  the  capability  to  write  National  and  local  patches  to  the  HCS  software. 

The  ACT  status  modifier  is  set  to  patch  when  the  source  is  not  provided  at  the  time 
of  the  problem.  A  patch  is  developed  to  correct  the  problem  until  the  source  is 
released.  The  ACT  status  is  updated  to  BUILD  (Step  #5)  phase  of  its  life  cycle, 
with  a  statxis  modifier  of  REQUEST. 

A. 5  STEP  45>  STATUS:  BUILD. 

Problems  assigned  for  resolution  requiring  a  source  change  will  be  Incorporated 
into  a  special  build.  The  purpose  of  the  build  is  to  test  assigned  problems  for 
compatibility  and  corrective  action. 

A.?.l _ Status  Modifier:  Request. 

When  source  code  is  modified,  the  software  developer  creates  a  software  ild 
during  this  life  cycle  phase,  then  the  status  modifier  is  set  to  "BUILD,  Request." 
When  the  software  build  is  complete,  the  status  modifier  is  updated  to  reflect  the 
outcome  of  the  build. 

A.5,g _ Status  Modifier:  Pass. 

If  the  correction  or  update  was  successfully  incorporated  into  a  logic  release 
plan,  the  status  modifier  is  set  to  "BUILD,  Pass.”  The  ACI  status  is  then  updated 
to  the  TEST  (Step  y/6)  phase  of  its  life  cycle. 

A. 5. 3  Status  Modifier:  Fail. 

If  the  correction  or  update  could  not  successfully  be  incorporated  into  the  logic 
release,  the  status  modifier  is  set  to  "BUILD,  Fail."  The  ACI  status  returns  to 
the  ASSIGN  (Step  //3)  phase  of  its  life  cycle. 

A. 6  STEP  V/6>  STATUS:  TEST. 


The  logic  release  or  adaptation  data  change  is  tested  with  the  correction  or 
revision  in  place.  Actual  steps  taken  in  this  phase  by  the  testing  organization 
will  vary  for  each  organization. 


If  the  logic  and/or  adaptation  data  was  tested  and  the  fomal  test  and 
deaonstratlon  have  been  conpleted  successfully,  then  the  status  modifier  is  set  to 
"TEST,  Pass."  The  ACI  status  is  updated  to  the  TRANSMIT  (Step  #7)  phase  of  its 
life  cycle. 

A. 6. 2  Status  Modifier:  Fail. 

If  the  formal  test  or  demonstration  failed,  the  status  modifier  is  set  to  "TEST, 
Fall."  If  the  ACI  requires  input  from  a  different  organization,  the  statixs  returns 
to  ASSIGN  (Step  #3).  If  the  ACI  can  be  resolved  by  the  current  organization,  the 
status  returns  to  RESOLVE  (Step  . 

A. £..3 _ Status  Modifier:  Notest. 

If  the  resolution  or  modification  does  not  require  testing  or  it  cannot  be  tested 
at  system  level,  the  status  modifier  is  set  to  "TEST,  Notest."  CCB  approval  is 
required  for  this  case.  The  ACI  status  is  updated  to  the  TRANSMIT  (Step  //7)  phase 
of  its  life  cycle. 

LlLJ* _ Status  Modifier:  Hold. 

If  the  test  results  need  further  evaluation  or  FAA  management  defers  the  test  until 
a  prerequisite  change  is  ready,  the  status  modifier  is  set  to  "TEST,  Hold."  When 
the  test  has  been  completed,  the  status  modifier  is  updated  to  reflect  the  outcome 
of  the  test. 

A. 7  STEP  ^^7>  STATUS:  TRANSMIT. 

The  resolving  organization  formally  submits  the  system  release  to  the  AOS 
organization  for  system  integration. 

Note:  There  are  no  status  modifiers  for  the  TRANSMIT  phase. 

A. 8  STEP  tf8>  STATUS:  INTEGRAT(E). 

All  corrective  actions  received  by  the  FAA  for  integration  into  an  operational 
system  is  incorporated  and  baselined  into  the  appropriate  system  release  plan. 

A. 8.1  Status  Modifier:  Request. 

The  resolving  organization  successfully  transmits  the  resolution  or  modification  to 
the  FAA.  The  FAA  integrates  the  resolution  into  the  system  release  plan  and  the 
status  modifier  is  set  to  "INTEGRAT,  Request." 

When  the  integration  is  complete,  the  status  modifier  is  updated  to  reflect  the 
outcome  of  the  integration. 

A.  8. 2  Status  Modifier:  Pass. 

The  FAA  integrates  the  correction  or  modification  into  the  system  release  plan 
successfully.  The  system  release  plan  is  baselined,  and  the  status  modifier  is  set 
to  "INTEGRAT,  Pass."  The  ACI  status  is  then  updated  to  VERIFY  (Step  #9). 
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If  the  FAA  is  luiable  to  integrate  the  correction  or  modification  into  the  system 
release  plan  or  is  unable  to  baseline  the  system  release  plan,  the  status  modifier 
is  set  to  "INTEGRAT,  Fail."  The  ACI  status  then  returns  to  ASSIGN  (Step  #3). 

A. 9  STEP  #9>  STATUS:  VERIFY. 

The  problem/change  has  successfully  reached  the  baseline  testing  phase  and  is 
verified  for  corrective  action.  During  this  phase,  the  originator  is  consulted  for 
final  verification  of  the  ACI's  disposition.  The  ACI  is  assigned  to  an  FAA  tester. 
The  FAA  tester  completes  final  testing  of  the  resolutions  and  modifications,  and 
the  status  modifier  is  updated  to  reflect  the  verification  results. 

A. 9.1 _ Status  Modifier:  Pass. 

When  the  resolution  or  modification  has  been  verified  with  no  degradation  to  the 
system,  the  status  modifier  is  set  to  "VERIFY,  PASS."  The  ACI  status  is  then 
updated  to  CLOSE  (Step  #10) . 

LJLl _ Status  Modifier:  Fall. 

If  the  problem  correction  did  not  test  successfully,  then  the  status  modifier  is 
set  to  "VERIFY,  Fail."  The  ACI  is  returned  to  the  resolving  organization  with  an 
ACI  status  of  ASSIGN  (Step  #3) .  If  the  ACI  failed  during  the  SCREEN  phase  of  the 
life  cycle,  the  originator  then  verifies  the  ACI  information,  and  the  ACI  is 
returned  to  the  SCREEN  (Step  #2)  phase  of  its  life  cycle. 

A, >,.9. 3 _ Status  Modifier:  Hold. 

If  the  problem  is  placed  on  hold,  pending  further  review,  the  status  modifier  is 
set  to  "VERIFY,  Hold."  FAA  management  may  elect  to  hold  an  ACI  until  a  subsequent 
system  release  has  been  created.  When  the  ACI  has  been  verified,  the  status 
modifier  is  updated  to  reflect  the  outcome  of  the  verification. 

A. 10  STEP  #10>  STATUS:  CLOSE. 

Before  an  ACI  can  be  closed,  the  adaptation  data  status  is  checked  along  with  the 
status  of  any  associated  nonlogic  components  and  RTRs.  If  an  ACI  affects 
adaptation  data,  the  adaptation  data  status  must  be  closed.  This  means  that  the 
associated  adaptation  data  must  be  baselined.  If  the  ACI  has  been  reassigned  to 
one  or  more  logic  releases,  all  associated  RTR  records  must  be  closed. 

Component  tracking  records  are  used  to  identify  and  track  members  in  the  library 
hierarchy,  as  well  as  commercial  hardware  and  software  changes.  Normally,  the 
person  implementing  the  change  creates  the  appropriate  component  tracking  records 
for  the  change.  A  component  record  is  associated  with  an  ACI  but  not  assigned  to  a 
logic  release.  If  component  records  have  been  created  for  the  ACI,  the  status  of 
these  components  must  also  be  closed. 

All  conditions  must  be  satisfied  before  the  ACI  can  be  closed.  The  Software 
Configuration  Library  Manager  (SCLM)  software  promotes  the  ACI  to  CLOSED  status 
when  all  of  the  work  for  the  ACI  is  complete.  Once  the  ACI  is  filed  with  a  status 
of  CLOSED,  the  status  cannot  be  changed. 
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If  the  revised  system  is  scheduled  to  be  deployed  to  the  field,  the  CCB  verifies 
that  all  of  the  Site  Program  Bulletin  and  Site  Technical  Bulletin  events  have 
occurred.  These  events  Include: 

a.  Notification  of  a  system  release  with  changes, 

b.  Preliminary  Documentation,  l.e.,  test  scripts,  training  needed, 

c.  Support  Software  which  is  executed  with  changes  via  remote  logon, 

d.  System  Source  Listings  which  provide  insight  into  the  logic, 

e.  System  Delivery  of  the  Version  Description  Document  (VDD)  header  files. 

AJ.O.aX _ Status  Modifier:  Shipped. 

If  all  procedures  have  been  completed  successfully  and  are  available  for 
deployment,  the  status  modifier  is  set  to  "CLOSED,  Shipped.”  The  resolution  or 
modification  is  deployed  to  the  field  as  a  source  correction  or  update.  The 
shipment  should  include  the  Site  Program  Bulletin  (SPB)  or  Site  Technical  Bulletin 
(STB)  number. 

A»iQ.2 _ Status  Modifier:  Noshio. 

If  the  problem  or  change  has  been  closed  but  the  resolution  or  modification  will 
not  be  shipped  to  the  field,  the  status  modifier  is  set  to  "CLOSED,  Noship"  and  the 
ACI  is  closed. 

A. 19. 3 _ Status  Modifier:  Reject. 

If  the  problem  or  change  has  been  rejected,  the  status  modifier  is  set  to  "CLOSED, 
Reject”  and  the  ACI  is  closed. 

AJJIlA _ Status  Modifier:  Hold. 

If  a  correction  or  revision  is  placed  on  hold  pending  the  preparation  of  one  or 
more  documents,  the  status  modifier  is  set  to  "CLOSED,  Hold."  The  CCB  may  hold  the 
implementation  of  a  resolution  or  modification  until  a  subsequent  release  has  been 
created.  When  the  ACI  is  ready  to  be  shipped,  the  status  modifier  is  updated  to 
reflect  the  closing  status  of  the  ACI. 
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APPENDIX  B 

ADAPTATION  DATA  UPDATE  PROCEDURES 


Adaptation  data  Is  the  set  of  data  values  used  to  adapt  the  functional  behavior  of 
the  operational  software  to  a  certain  center's  needs.  Site  adaptation  data 
specialists  enter  site-specific  adaptation  data,  such  as  geographical  data, 
Installation  data,  and  site-specific  system  parameters.  National  adaptation  data 
specialists  at  the  FAA  Technical  Center  (AOS)  enter  adaptation  data  that  applies  to 
all  centers,  such  as  aircraft  and  static  Information  data. 

Adaptation  data  can  be  grouped  Into  two  general  classes:  environmental  and 
nonenvlronmental .  Environmental  adaptation  data  describes  the  geographical  and 
physical  characteristics  of  a  given  ARTCC  and  Is  subject  to  update  activity  based 
on  real-world  conditions  or  events.  Nonenvlronmental  adaptation  data  consists  of 
system  control  tables  or  other  software  oriented  parameters  which  provide  the 
flexibility  and  maintenance  benefits  of  data-driven  air  traffic  control  (ATC) 
software.  This  class  of  data  Is  updated  along  with  Incremental  software 
enhancements  or  periodic  tuning  activities. 

Environmental  adaptation  data  occurrences  are  entered  Interactively  through  one  or 
more  data  Input  panels,  or  In  specific  cases,  via  batch  Input  files.  The  input 
panels  supply  default  Information  and  prompt  the  data  collector  for  additional 
Information.  Nonenvlronmental  adaptation  data  occurrences  are  entered  exclusively 
from  batch  Input  files.  Once  the  data  has  been  entered  Into  the  adaptation  data 
databases.  Configuration  Management  (CM)  Is  performed  following  the  same  status  and 
approval  cycles  by  which  all  adaptation  data  updates  are  managed. 

In  general,  the  adaptation  data  specialist  is  responsible  for  determining  what  data 
needs  to  be  updated.  This  specialist  may  have  originated  the  ACI  or  may  have  been 
assigned  to  handle  the  data  changes  In  an  ACI  from  another  source. 


The  data  collection  software  provides  its  own  CM  at  the  adaptation  data  occurrence 
level.  This  additional  control  Is  necessary  because  adaptation  data  Is  stored  In 
DB2  tables  and  Is  not  directly  controlled  by  the  INFO  Family. 

The  data  collection  software  maintains  a  life  cycle  status  for  each  adaptation  data 
occurrence.  Possible  status  values  are  FENDING,  FROZEN,  TEST,  and  BASELINE. 

a.  PENDING.  The  Initial  status  of  an  adaptation  data  occurrence  Is 
automatically  set  to  PENDING.  This  data  may  be  Incomplete,  with  future  updates  to 
an  occurrence  pending  completion.  Only  PENDING  occurrences  may  be  modified  or 
deleted  by  authorized  personnel.  Upon  completion  of  the  occurrence  data  entry 
step,  the  user  may  "freeze"  the  data. 

b.  FROZEN.  A  FROZEN  occurrence  signifies  that  data  updates  for  that 
occurrence  are  complete.  FROZEN  data  is  placed  under  configuration  control  and 
further  updates  are  prevented  during  the  review  and  approval  process.  When  an 
occurrence  is  FROZEN,  a  list  of  reviewers  for  that  occurrence  is  automatically 
created  by  the  software. 

c.  TEST.  TEST  is  a  higher  level  of  CM  which  may  be  used  to  indicate  that 
data  has  been  passed  jo  a  system  test  organization.  However,  testing  of  data  may 
be  performed  at  any  point  in  its  life  cycle  after  incorporating  it  into  a  system 
release  via  the  Plan  System  Release  function. 


Occurrences  with  a  status  of  FROZEN  or  TEST  snist  be  denoted  to  PENDING  status 
before  updates  can  be  made  to  the  occurrence. 

d.  BASELINE.  BASELINE  Is  the  highest  level  of  CM.  BASELINE  occurrences 
can  no  longer  be  changed  by  the  user.  An  occurrence  should  only  be  promoted  to 
BASELINE  when  all  changes  and  all  testing  for  that  occurrence  are  complete. 

One  exception  to  this  rule  is  the  fact  that  certain  CM  data;  e.g.,  last  effective 
data,  can  be  changed  using  the  Data  Collection  utilities  after  the  occurrence  has 
been  BASELINE. 

To  promote  the  status  of  a  data  occurrence  to  FROZEN,  TEST,  or  BASELINE,  the  data 
imist  have  a  validation  status  of  "valid,"  signifying  the  data  has  passed  the  Data 
Collection's  contextual  validation  checks.  The  "valid"  status  implies  that  the 
data  is  syntactically  correct  and  complete  and  is  in  compliance  with  the 
established  category- specific  occurrence  definition. 

The  validation  status  can  be  changed  only  by  the  Data  Collection  software.  An 
occurrence  is  determined  to  be  "valid"  when  the  Data  Collection  software  Indicates 
that  the  occurrence  is  complete  and  correct  based  on  a  set  of  predefined  rules 
within  the  software.  This  determination  is  made  when  an  occurrence  is  created  and 
whenever  changes  to  the  occurrence  are  made. 

B.1.1 _ Data  Collection. 

Prior  to  entering  adaptation  data,  an  ACI  must  be  opened.  Under  AAS,  all  changes 
to  adaptation  data  must  be  documented  by  ACIs.  The  "Open  ACI"  step  in  the  ACI  life 
cycle  is  described  in  detail  in  appendix  A,  The  Ten-Step  ACI  Life  Cycle, 

Adaptation  data  is  entered  by  the  personnel  or  organization  responsible  for  the 
real-world  object  or  state  described  by  the  data.  The  data  may  be  entered 
interactively  or  in  batch  mode,  depending  on  the  category.  Generally,  when  data  is 
batch  input,  the  occurrence  merely  points  to  the  data  set  that  contains  the  data. 

The  data  entry  panels  of  the  AAS  ATC  Operational  Support  and  Change  Tracking 
software  prompt  the  user  to  enter  appropriate  data  that  describes  an  occurrence  of 
a  particular  category.  The  prompting  panels  request  and  then  store  the  parameters 
that  correctly  describe  the  occurrence.  For  categories  that  require  a  variable - 
length  list  of  values,  the  user  is  prompted  for  multiple  entries  in  the  list  until 
the  user  indicates  that  the  list  is  complete. 

The  adaptation  data  management  system  has  the  capability  to  initialize  the 
parameter  value  fields  for  a  new  occurrence  with  values  from  an  existing 
occurrence.  This  capability  allows  an  existing  occurrence  to  be  used  as  a 
template  for  the  entry  of  similar  occurrences.  Once  the  new  occurrence  has 
been  initialized,  the  user  may  then  modify  parameters  to  create  the  new 
occurrence . 

As  data  is  being  entered,  constraint  checking  is  performed  at  two  levels.  First, 
as  each  Individual  parameter  is  entered,  it  is  automatically  checked  against 
predetermined  constraints  for  that  parameter.  These  constraints  may  be  format, 
dimension,  or  value  constraints.  Second,  when  the  user  specifies  that  11  values 
for  an  occurrence  have  been  entered,  the  occurrence  is  automatically  checked  to 
verify  that  constraints  involving  more  than  one  parameter  are  met. 
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Any  failure  of  either  type  of  constraint  checking  Is  recorded  along  with  the 
occurrence  unless  the  user  corrects  the  values  of  the  offending  parameters.  The 
user  may  Invoke  the  display  format  adaptation  data  checking  function  at  any  stage 
of  the  entry  process. 

The  source  adaptation  data  which  Is  collected  during  this  step  Is  used  in  the 
Construct  System  Release  step  In  order  to  prepare  the  data  products  that  are  sent 
to  each  center. 

The  entry  of  adaptation  data  Is  complete  when  the  user  promotes  the  adaptation  data 
to  a  status  of  FROZEN.  This  status  change  causes  the  occurrence  to  be  stored  In 
the  adaptation  database  with  Indicators  set  that  prevent  any  further  attempt  by  the 
user  to  modify  It. 

To  enter  adaptation  data,  the  Data  Collection  option  is  selected  from  the  AAS  ATC 
Operational  and  Change  Tracking  Menu. 

B.1.2  Freeze  Adaptation  Data. 

The  user  freezes  an  occurrence  when  they  are  certain  that  the  entered  modified  data 
is  complete  and  correct.  After  the  occurrence  has  been  frozen,  no  more  changes  may 
be  made  to  the  adaptation  data.  The  user  may  freeze  an  occurrence  only  when  the 
validation  status  of  the  occurrence  is  "valid"  and  the  user  is  ready  for  the 
occurrence  to  be  reviewed  via  the  review/approve  process. 

To  freeze  adaptation  data,  the  Data  Collection  option  is  selected  from  the  AAS  ATC 
Operational  and  Change  Tracking  Menu. 

P.l.S _ Review/Approve  Adaptation  Data. 

"Freezing"  an  occurrence  allows  the  ACI  review  process  to  begin,  during  which  the 
proposed  new  or  changed  data  Is  reviewed,  tested,  and  approved.  Updating, 
reviewing,  and  testing  data  changes  are  typically  iterative  processes.  Since  data 
occurrence  values  cannot  be  changed  while  in  FROZEN  or  TEST  status,  the  occurrence 
must  be  demoted  to  PENDING  status  in  order  to  repeat  the  cycle. 

Only  the  personnel  with  the  proper  review  and  approval  authorization  level  can 
"thaw"  the  frozen  occurrence  and  return  it  to  the  FENDING  status  for  further  user 
modification.  This  precaution  assures  that  the  data  in  the  review  cycle  cannot  be 
changed  during  the  review,  while  at  the  same  time  it  allows  the  submitter  to  make 
necessary  corrections  or  changes. 

Every  occurrence  must  be  reviewed  and  approved  before  it  can  be  promoted  to  the 
BASELINE  status.  When  an  occurrence  is  promoted  from  the  PENDING  status  to  either 
the  FROZEN  or  TEST  status,  the  support  software  automatically  generates  a  list  of 
reviewers  for  that  occurrence. 

The  support  software  generates  the  list  of  reviewers  by  searching  its  databases  for 
the  u«!«rs  that  have  the  authority  to  access  the  "approve"  function.  This  list  can 
be  tailored,  via  other  Data  Collection  functions,  to  include  only  those  users  that 
are  critical  to  the  review  of  the  particular  occurrence.  These  reviewers  may  be 
adaptation  specialists,  informal  test  personnel,  formal  test  personnel,  management, 
etc. 
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Each  reviewer  is  responsible  for  reviewing  the  occurrence  for  completeness  and 
accuracy.  The  reviewers  confirm  that  the  occurrence  is  correct  in  relation  to 
other  occurrences  in  the  category  and  any  associated  occurrences  in  other 
categories . 

The  Data  Collection  and  System  Release  Plan  Preparation  functions  of  the  support 
software  assist  the  user  in  determining  the  validity  of  the  occurrence  values,  but 
only  the  reviewers  can  be  certain  if  the  occurrence  is  correct  for  the  situation 
and  environment  in  which  it  will  be  used. 

Review  involves  examination  of  displayed  or  printed  images  of  a  submitted 
occurrence.  The  purpose  of  the  review  activity  is  to  make  appropriate  personnel 
aware  of  any  and  all  proposed  changes  or  additions  to  adaptation  data.  The 
examination  may  be  made  by  the  person  who  entered  the  data,  that  persoii's 
supervisor,  appropriate  personnel  from  related  facilities,  a  central  authority  at 
the  FAA  Technical  Center  or  FAA  headquarters,  or  any  number  of  other  possible 
people,  depending  on  the  purpose  of  the  submitted  data.  For  data  used  only  to 
support  test  cases,  the  review  may  involve  only  development  personnel,  while  for 
data  that  will  be  used  to  describe  actual  ATC  environmental  or  operational 
elements,  the  review  may  involve  a  broad  spectrxim  of  people,  from  operational  to 
maintenance  personnel. 

The  determination  by  the  appropriate  personnel  that  the  changes  are  complete  and 
correct  is  made  category  by  category.  Creation  and  submission  of  a  new  occurrence 
of  a  category  makes  the  data  available  to  the  appropriate  personnel.  The  software 
supporting  the  review  operates  through  the  SSCC  and  is  available  to  users  through 
interactive  display  panels  specifically  designed  for  this  use. 

Approval  of  a  submitted  occurrence  is  solicited  from  each  reviewer,  recorded,  and 
saved  as  a  part  of  the  occurrence.  Thus,  the  category  contains  information  about 
each  reviewer,  including  identity,  the  level  of  authority  (absolute,  advisory,  or 
information  only),  and  approval,  rejection,  or  comment.  The  actual  baselining  of 
new  or  modified  adaptation  data  occurrences  is  an  event  marked  by  the  final 
approval  of  each  occurrence. 

The  adaptation  data  category,  in  addition  to  providing  prompting  information  for 
all  required  and  optional  data  to  be  collected  for  each  occurrence,  provides  a  list 
of  the  reviewers  to  be  notified  whenever  a  new  occurrence  for  that  categoiy  type  is 
submitted.  The  occurrence  contains  the  actual  data  that  defines  the  object,  flags 
describing  the  purpose  of  the  object  (e.g.,  test,  operations,  etc.},  and  approval 
information  from  each  reviewer.  Progress  during  the  review  cycle  can  be  determined 
by  examining  the  approval  fields. 

To  review/approve  adaptation  data,  the  Data  Collection  option  is  selected  from  the 
AAS  ATC  Operational  and  Change  Tracking  Menu. 

B.1.4  Demote  Data. 

Once  an  occurrence  is  in  the  FROZEN  or  TEST  status,  no  changes  can  be  made  to  the 
occurrence.  To  make  changes  to  an  occurrence  that  has  been  promoted  to  FROZEN  or 
TEST,  the  occurrence  must  first  be  "demoted"  back  to  PENDING. 
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When  «n  occurrence  is  demoted  to  PENDING,  the  list  of  reviewers  for  that  occurrence 
Is  deleted.  When  the  occurrence  is  then  repromoted  to  l^OZEN  or  TEST,  the  list  of 
reviewers  is  recreated  and  the  approval  cycle  starts  again. 

To  demote  adaptation  data,  the  Data  Collection  option  is  selected  from  the  AAS  ATC 
Operation  and  Change  Tracking  Menu. 

B.2  SYSTEM  RELEASE  PLAN  PREPARATION. 

After  the  adaptation  data  has  been  approved,  the  system  release  is  prepared  by 
specifying  a  system  release  plan.  A  separate  system  release  is  deployed  to  each 
center  because  a  system  release  is  tailored  specifically  for  the  center  to  which  it 
is  deployed.  Once  the  system  release  plan  has  been  completed,  the  adaptation  Heta 
is  converted  into  data  products. 

When  a  system  release  is  prepared,  the  required  adaptation  data  is  extracted  from 
the  database,  then  the  data  is  converted  to  the  data  product  format  and  placed  into 
data  products  for  use  with  the  operational  software.  A  system  release  plan  must  be 
created  before  the  data  products  can  be  generated.  The  system  release  plan  is  also 
required  for  integration  and  formal  testing  of  operational  logic  releases . 

There  are  two  major  components  in  a  System  Release:  the  logic  release  ID,  and  the 
constructed  data  products. 

Once  the  system  release  has  been  deployed  to  the  site,  it  is  downloaded  to  the 
appropriate  processors  for  final  testing  and  cutover.  These  tasks  are  described  in 
the  ARTCC  System  Maintenance  and  Support  Manual  and  the  ARTCC  System  Management 
Manual . 

B.2.1  Build  System  Release  Plan. 

To  plan  a  system  release,  the  System  Planning  option  is  selected  from  the  AAS  ATC 
Operational  Support  and  Tracking  Menu.  The  system  release  plan  identifies  the 
components  of  a  system  release,  (i.e.,  which  logic  release  and  which  data  products 
are  to  be  used) . 

B.2. 1.1  Selecting  a  Logic  Release. 

Because  adaptation  data  is  so  closely  tied  to  the  ATC  Operational  Software  (logic 
release),  each  system  release  plan  must  specify  the  logic  release  with  which  the 
data  is  to  be  used.  The  logic  release  must  already  have  been  created  using  the 
Logic  Release  Planning  functions,  which  are  described  in  appendix  C.  The  logic 
release  must  at  least  have  a  status  of  OPEN. 

B.2.1.2  Constructing  Data  Products. 

Once  the  system  release  plan  is  created,  the  adaptation  data  must  be  constructed 
into  data  products.  During  the  data  construction  phase,  the  occurrences  which  are 
to  be  used  for  the  data  product  are  selected,  any  additional  validation  that  was 
not  performed  in  the  Data  Collection  step  is  performed,  and  the  occurrences  are 
combined  and  reformatted  into  a  computer  readable  format,  or  a  data  product. 
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The  construction  step  may  be  run  only  when  the  system  release  contains  adaptation 
data.  If  the  system  release  contains  only  logic,  there  are  no  adaptation  data 
products  to  construct,  and  this  step  Is  b)rpassed. 

Since  the  construction  step  creates  the  data  products  that  are  used  by  the  system 
release,  the  construct  step  must  be  run  before  the  "test  ship"  or  "deploy"  steps. 

To  construct  a  system  release,  the  Data  Construction  option  Is  selected  from  the 
AAS  ATC  Operational  Support  and  Tracking  Menu. 

B.2.2  Test  Shin  System  Release. 

The  user  may  ship  a  constructed  system  release  with  a  status  of  PENDING  to  a  center 
or  to  the  System  Support  Facility  (SSF)  for  Informal  testing.  This  gives  the  user 
the  ability  to  fully  test  the  system  release  ana  to  make  any  necessary  changes  to 
the  system  release  before  the  system  release  is  BASELINE.  A  BASELINE  system 
release  cannot  be  modified,  which  means  that  any  errors  found  In  a  "baseline" 
system  release  can  be  corrected  only  by  creating  another  system  release. 

The  adaptation  data  products  corresponding  to  the  developed  adaptation  data  are 
test  shipped  via  tape  or  electronic  link  from  the  Technical  Center  to  the  center 
where  they  can  be  tested  Independently  of  the  other  contents  of  the  system  release. 

Modifying  data,  construction,  and  testing  of  the  system  release  will  be  an  ongoing 
loop  until  the  user  Is  satisfied  with  the  system  release.  The  user  constructs  and 
tests  the  system  release.  The  user  then  makes  any  necessary  changes  and  constructs 
and  tests  the  system  release  again.  This  process  continues  until  all  tests  have 
been  executed  successfully  and  the  user  Is  satisfied  with  the  constructed  system 
release. 

To  test  ship  a  system  release,  the  System  Distribution  option  is  selected  from  the 
AAS  ATC  Operational  Support  and  Tracking  Menu. 

B.2.3  Test  System  Release. 

The  test  system  release  step  is  performed  at  the  ARTCC  or  SSF  that  receives  the 
test  shipment.  During  this  phase,  the  tester  thoroughly  tests  the  system  release 
or  partial  system  release,  whichever  is  appropriate.  Inputs  required  for  testing 
Include  test  scenarios  and  test  versions  of  logic  and  adaptation  data. 

If  the  test  Is  successful,  the  data  update  process  continues  with  test  shipment  to 
key  test  centers  or  to  other  particular  centers  for  further  testing,  as  the 
situation  demands.  Otherwise,  any  problems,  such  as  a  logic  error  or  an  Improper 
test  configuration,  must  be  analyzed  and  resolved  before  key  center  testing. 

To  completely  test  an  operational  logic  release.  It  would  have  to  be  tested  with 
every  possible  combination  of  site-specific  adaptation  data.  The  most  appropriate 
strategy  possible  for  SSF  testing  is  using  Universal  Data  Sets  (UDSs)  to  test  ACIs 
when  It  Is  Impractical  to  test  against  a  large  number  of  different  adaptation  data 
sets.  Consequently,  the  rigorous  testing  process  at  centers  will  still  be  required 
under  ISSS  as  performed  In  the  past. 
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tAA _ Baseline  Adaptation  Data. 


Once  all  of  the  adaptation  data  has  been  collected,  reviewed,  and  successfully 
tested,  it  is  ready  to  be  BASELINE. 

B.2.5 _ Baseline  System  Release  Plan. 

A  system  release  plan  can  have  a  status  of  PENDING  or  BASELINE.  The  AAS  software 
requires  a  system  release  to  be  baseline  before  It  is  deployed  to  a  center.  This 
is  to  ensxire  that  a  system  release  cannot  be  changed  after  It  has  been  deployed. 
Baselining  a  system  release  freezes  the  data  products  so  that  they  cannot  be 
changed. 

A  system  release  is  baseline  only  when  it  has  been  tested  successfully  and  is  ready 
for  deployment  to  the  center  for  certification  and  installation.  Baselining  a 
system  release  does  not  affect  the  source  adaptation  data  that  was  used  by  that 
system  release. 

To  baseline  a  system  release  plan,  the  System  Planning  option  is  selected  from  the 
AAS  ATC  Operational  Support  and  Tracking  Menu. 

_ Deploy  System  Release. 

The  deploy  function  sends  an  AAS  system  release  to  a  specific  center.  The  deployed 
system  release  includes  a  specified  set  of  constructed  data  products,  static  data, 
and  logic  release  data  sets.  The  contents  of  the  deployed  system  release  are 
determined  by  the  user  in  the  plan  system  release  step. 

The  AAS  software  d.lc't  ates  that  only  BASELINE  system  releases  can  be  deployed,  and 
the  associated  logic  release  must  have  a  status  DEPLOY,  even  if  the  logic  itself  is 
not  being  deployed  with  the  system  release. 

To  deploy  a  system  release,  the  System  Distribution  option  is  selected  from  the  AAS 
ATC  Operational  Support  and  Tracking  Menu. 

B.2.7  Report  Receipt. 

Once  the  deployed  system  release  has  been  received  at  the  center,  the  site 
personnel  report  receipt  of  the  system  release.  The  CM  rules  dictate  that  a 
"report  receipt"  must  be  made  before  the  "report  cutover"  step  is  performed. 

Only  a  deployed  system  release  may  be  reported  as  received  at  a  center,  the  AAS 
software  does  not  support  the  reporting  of  a  "test  shipped"  system  release. 

B.2.8  Close  Adaptation  Data. 

Once  the  adaptation  data  changes  have  been  made  and  deployed  to  a  center  via  the 
system  release,  the  data  portion  of  the  ACI,  used  to  track  the  changes,  can  be 
closed. 

The  adaptation  portion  of  the  ACI  must  be  closed  before  the  ACI  can  be  closed. 

Once  all  of  the  occurrences  that  were  created  for  the  ACI  are  baseline,  the  ACI  can 
be  closed  to  adaptation  data. 
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To  close  adaptation  data,  the  Change  Tracking  option  Is  selected  from  the  AAS  ATC 
Operational  Support  and  Tracking  Menu. 

ClQgg  ACI- 

Closing  the  ACI  Is  the  last  step  to  be  performed.  Closure  of  the  ACI  Indlcr-tes 
that  all  work  related  to  the  ACI  Is  complete.  Since  the  system  release  can  be 
Installed  at  the  center  before  the  ACI  Is  closed,  thir  activity  Is  of  low 
criticality. 

When  all  centers  have  reported  cutover  to  a  system  release,  all  release  tracking 
records  for  the  logic  release  that  have  been  deployed,  are  closed.  The  ACIs  with 
closed  release  tracking  records  will  also  be  closed  at  this  point. 

To  close  an  ACI,  the  Change  Tracking  option  Is  selected  from  the  AAS  ATC 
Operational  Support  and  Tracking  Menu. 
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APPENDIX  C 


LCXJIC  UPDATE  PROCEDURES 


NOTE:  This  section  is  written  to  address  the  procedures  for  updating  operational 
software.  These  procedures  could  also  be  applied  for  updating  AAS  developed 
software . 

A  logic  release  is  a  set  of  related  software  used  to  generate  a  deliverable  system. 
A  logic  release  plan  Includes  a  schedule  for  building  and  promoting  a  logic  release 
and  a  record  of  all  the  ACIs,  and  associated  software  and  document  components,  that 
are  included  in  the  logic  release .  A  logic  release  plan  is  necessary  to  develop 
and  deliver  a  logic  release. 

The  four  CM  statuses  that  a  logic  release  plan  can  go  through  are  NEW,  OPEN, 

CLOSED,  and  DEPLOY. 

a.  NEW.  The  logic  release  plan  is  created  and  its  status  set  to  NEW  when  the 
project  definition  Identifying  the  hierarchy  for  the  release  is  built  by  the  SCLM 
administrator.  The  only  logic  planning  function  available  for  a  logic  release  with 
a  status  of  NEW  is  to  initiate  (open)  the  plan. 

b.  OPEN.  A  status  of  OPEN  indicates  the  planning  and  development  functions 
for  the  logic  release  plan  can  begin.  The  ACIs  may  be  scheduled  for  implementation 
in  a  logic  release  via  the  Change  Tracking  option  when  the  plan  has  a  status  of 
OPEN. 


c.  CLOSED.  A  CLOSED  status  prevents  ACIs  from  being  scheduled  for 
implementation  in  that  logic  release.  The  only  changes  that  may  be  made  to  the 
plan  are  to  set  the  status  to  DEPLOY  and  to  modify  the  compatibility  data. 
Compatibility  data  associates  a  support  software  logic  release  with  one  or  more 
operational  software  releases.  It  is  described  more  fully  in  a  later  section. 

d.  DEPLOY.  A  DEPLOY  status  is  used  after  all  development  and  testing  of  the 
logic  release  is  complete.  It  allows  the  logic  release  to  be  deployed  to  a  center. 
The  logic  release  plan  can  only  be  set  to  deploy  after  the  code  and  associated 
documentation  has  been  promoted  to  the  release  level. 

C.l  LOGIC  RELEASE  PLANNING. 

The  plan  logic  release  function  is  used  for  all  tracking  functions  pertaining  to 
developing  a  logic  release,  from  initiating  the  logic  release  plan  to  Implementing 
the  changes  to  delivering  the  code. 

C.1.1  Create  a  Library  Hierarchy  for  a  Logic  Release. 

Operational  code  and  documentation  is  maintained  in  a  hierarchical  library 
management  system  called  System  Configuration  Library  Manager  (SCLM) .  There  are 
three  types  of  work  associated  with  SCLM.  The  SCLM  administrators  (ACN-600) 
allocate  datasets,  maintain  SCLM  hierarchies,  and  provide  the  tools  to  support 
various  types  of  files  under  SCIM  like  Ada,  Bookmaster,  and  FEXX. 

To  set  up  the  library  for  a  new  release  of  operational  code ,  AOS ,  or  the 
organization  modifying  the  software,  will  contact  the  SCLM  to  create  the  logic 
release  plan.  The  SCLM  administrator  will  allocate  the  datasets  and  define  the 
library  hierarchy  for  the  logic  release.  The  hierarchy  is  defined  as  a  SCIM 
project  definition.  This  project  definition  identifies  all  library  types  and 
sections  necessary  for  the  development,  testing,  and  deplo3nnent  of  the  logic 
release . 
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The  hierarchy  for  the  development  of  one  logic  release  Includes  exactly  one  release 
level  and  one  or  more  levels  for  formal  test,  integration  testing,  and  development 
testing.  One  logic  release  and  one  library  structure  can  be  used  to  make  many 
logic  changes.  Each  maintainer  would  normally  have  an  individual  level,  but  they 
may  be  shared. 

There  are  three  user  levels;  (1)  one  Development  Integration  Level  (DEV), 

(2)  one  Integration  Test  Level  (INT) ,  and  (3)  one  Release/Forraal  Test  Level  (REL) . 
Additional  levels  may  be  added  to  the  hierarchy,  depending  on  how  many  steps  there 
are  in  the  test  procedures.  For  example,  if  there  are  three  types  of  formal  test, 
you  may  want  to  set  up  three  different  levels  in  the  hierarchy  for  these  three 
different  test  activities.  This  would  allow  each  test  organization  to  have  its  own 
isolated  environment. 

Library  structures  and  logic  releases  have  a  one-to-one  relationship.  Each  logic 
release  is  contained  in  one  main  library  structure,  but  there  may  be  several  test 
library  structures  associated  with  that  logic  release.  Each  library  structure  can 
contain  one  and  only  one  logic  release.  If  the  hierarchy  is  used  to  develop  a 
delta  logic  release,  there  will  be  one  or  more  base  levels  for  prior  releases  above 
the  release  level  for  the  current  release.  The  code  for  the  current  release  may 
not  be  promoted  into  the  levels  of  the  previous  releases. 

Once  the  SCLH  project  definition  is  defined,  it  must  be  assembled  under  SCLM  using 
the  Library  Definition  Translator  provided  by  AAS.  This  creates  a  logic  release 
plan  with  a  status  of  NEW. 

g.1.2 _ Initiate  a  Logic  Release  Plan. 

When  a  logic  release  is  created,  the  first  planning  function  performed  is  the 
initiation  of  the  logic  release  plan.  During  the  initiate  function,  the  user 
defines  basic  planning  information  for  a  logic  release,  such  a.s  the  logic  release 
title,  purpose,  and  planned  release  date.  Schedule  information  is  added  for  builds 
and  promotes  for  each  library  level  in  the  library  hierarchy  and  the  status  is  set 
to  OPEN. 

Logic  release  plans  may  be  subdivided  into  incremental  plans.  An  increment  is  a 
testable  subset  of  a  logic  release  and  is  created  to  divide  a  large  logic  release 
into  smaller,  more  manageable  units  for  testing.  An  increment  is  not  deployable. 

If  a  logic  release  is  small  enough  to  test  as  a  whole,  increments  are  not  used.  In 
general ,  Increment  plans  are  set  up  and  used  15.ke  logic  release  plans . 

To  initiate  a  logic  release,  the  logic  planning  option  is  selected  from  the  AAS  ATC 
Operational  Support  and  Tracking  Menu. 

C.1.3  Define  the  Contents  of  a  Logic  Release. 

Once  a  logic  release  plan  has  been  initiated,  changes  to  the  logic  release  are 
defined  by  assigning  ACI^  to  the  logic  release.  The  ACIs  and  logic  release  plans 
have  a  many-to-many  relationship.  One  logic  release  can  consist  of  one  or  more 
ACIs,  and  one  ACI  can  be  assigned  to  one  or  more  logic  releases.  This  many-to- 
many  relationship  allows  the  user  to  handle  more  than  one  change  in  a  logic  release 
and  to  Implement  a  change  in  multiple  baselines.  This  is  particularly  useful  when 
making  an  emergency  fix  in  the  field  and  incorporating  that  same  change  in  the  next 
regularly  scheduled  release. 
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When  an  ACI  affects  logic,  it  is  assigned  to  a  logic  release  when  it  has  a  status 
of  SCREEN  or  RESOLVE. 

In  order  to  assign  an  ACI  to  a  logic  release,  a  release  tracking  record  (RTR)  must 
be  created  using  the  logic  planning  function.  One  RTR  tracks  one  ACI  in  one  logic 
release.  If  an  ACI  is  implemented  in  more  than  one  release,  the  RTR  must  be 
created  for  each  release  in  which  it  is  implemented.  Note  that  the  RTR  tracks 
logic  releases,  not  system  releases. 

Because  the  RTRs  are  used  to  track  an  ACI,  they  have  the  same  CM  statuses  as  an 
ACI.  The  status  of  the  RTR  allows  the  user  to  track  each  ACI  within  the  logic 
release  separately.  Vftien  RTRs  exist  for  an  ACI,  the  status  of  the  ACI  normally 
stays  at  SCREEN  or  RESOLVE  until  all  RTRs  associated  with  it  are  closed.  At  that 
point,  the  original  ACI  is  closed. 

To  assign  an  ACI  to  the  logic  release,  the  Change  Tracking  option  is  selected  from 
the  AAS  ATC  Operational  Support  and  Tracking  Menu. 

_ Initiate  Component  Trackine  Records. 

Each  component  in  the  library  hierarchy  that  must  be  edited  to  implement  an  ACI 
must  be  identified  and  tracked  via  a  component  tracking  record.  Component  tracking 
records  may  also  be  used  to  track  commercial  hardware  and  software  changes  that  may 
or  may  not  be  associated  with  a  logic  release.  Normally,  the  person  implementing 
the  change  woulo  create  the  appropriate  component  tracking  records  for  the  change. 

Four  types  of  components  can  be  tracked  by  the  tracking  function:  (1)  software,  (2) 
hardware,  (3)  commercial  off-the-shelf  (COTS)  software,  and  (4)  documents.  A 
component  has  a  status  of  OPEN  or  CLOSED.  A  component's  status  is  set  to  OPEN  when 
a  component  tracking  record  is  created. 

The  Information  in  the  component  tracking  record  includes  the  ACI  number,  the  logic 
release  ID  (if  appropriate),  scheduling  information,  a  description  of  the  work  to 
be  done  on  the  component,  the  impact  of  the  work  (e.g.,  labor  months,  source  lines 
of  code) ,  the  person  to  whom  the  work  is  assigned,  and  other  data  that  further 
Identifies  or  describes  the  component. 

In  addition  to  tracking  component  development,  component  tracking  data  is  used  to 
produce  discrepancy  reports  when  a  logic  release  or  increment  is  promoted.  This 
applies  only  to  software  and  document  components  that  are  part  of  a  logic  release. 
For  example,  if  a  user  tries  to  promote  a  logic  release  that  includes  a  specific 
software  component,  but  no  tracking  record  has  been  created  for  the  component,  then 
a  discrepancy  report  on  the  promotion  is  produced,  identifying  the  extra  component. 
The  promotion  is  prevented  if  any  discrepancies  are  found.  The  promotion  can 
continue  only  if  the  requestor  has  special  authority  to  override  the  discrepancy. 

A  closed  component  tracking  record  may  not  be  modified.  The  CLOSED  status 
indicates  that  all  work  on  the  component  is  complete.  All  components  associated 
with  a  release  must  be  closed  before  the  associated  RTR  may  be  closed.  All 
components  not  associated  with  a  release  must  be  closed  before  the  ACI  can  be 
closed. 
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To  Initiate  a  component  tracking  record,  the  Component  Tracking  option  is  selected 
from  the  AAS  ATC  Operational  Support  and  Tracking  Menu. 

C.2  DEVELOP  AND  TEST  LOGIC. 

After  all  planning  functions  are  complete,  the  maintainer  develops  and  tests  the 
required  logic  in  order  to  resolve  the  problems  or  implement  the  changes  detailed 
in  the  ACls. 

C.2.1 _ Loeic  Development. 

Logic  development  begins  with  the  analysis  of  the  ACIs  by  personnel  who  are  already 
familiar  with  the  operation  and  structure  of  the  software.  Generally,  the  outcome 
of  this  analysis  is  an  estimate  of  the  number  of  Source  Lines  of  Code  (SLOC) 
affected,  requirements  for  new  or  additional  documentation,  and  resources  req\'lred 
for  testing  and  training.  For  details  regarding  software  development,  see  section 
4.1.7,  Software  Development  and  Test. 

The  implementation  of  a  change  in  software  may  also  involve  the  addition  or 
correction  of  adaptation  data.  Preset  adaptation  data  is  maintained  AOS  in  the 
same  way  as  operational  logic.  Other  adaptation  data  is  maintained  by  Site 
Adaptation  Data  Specialists. 

The  output  of  the  development  activity  is  the  logic  release,  which  consists  of  the 
load  modules  that  were  generated  by  compiling,  link  editing,  and  binding  the 
developed  logic.  At  the  completion  of  this  activity,  the  logic  is  ready  for 
testing. 

The  SW  Development  option  is  selected  from  the  AAS  Administration  and  System 
Support  Menu  to  edit,  build,  and  promote  code. 

C.2 .2  Unit  Test  the  Software. 

Once  AOS  has  edited  the  software,  the  component  for  unit  testing  is  built.  Unit 
testing  takes  place  at  the  Job  Shop,  within  or  outside  of  the  SCLM  tool.  When  the 
component  has  been  tested,  the  developer  will  promote  the  component  up  to  an 
integration  level  in  the  hierarchy. 

C.2. 3  Modify  Compatibility  Data. 

Compatibility  data  is  used  to  associate  a  support  logic  release  with  one  or  more 
operational  logic  releases  that  run  at  an  ARTCC.  This  data  Identifies  the  version 
of  the  support  software  to  be  used  to  create  the  adaptation  data  products  for  the 
new  release. 

For  example,  when  an  Operational  Unit  (OU)  requires  a  new  adaptation  data  product, 
the  new  version  of  the  support  software  that  was  created  to  produce  the  data 
product  must  be  used  to  create  the  adaptation  data  for  the  new  operational  logic 
release.  The  compatibility  data  contains  the  necessary  information  for  choosing 
the  correct  version  of  software  to  use. 
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As  new  system  releases  are  created,  a  new  operational  logic  release  may  require  a 
change  to  the  existing  support  logic  release.  Previous  operational  logic  releases 
may  then  be  compatible  with  the  new  support  logic  release.  In  that  case,  both  the 
new  operational  logic  release  and  any  old  operational  logic  releases  still  in  use 
are  marked  as  compatible  with  the  new  support  logic  release.  This  reduces  the 
nvmber  of  support  logic  releases  chat  must  be  maintained. 

Compatibility  data  is  modified  by  the  software  maintainer  or  logic  release  planner 
for  open,  closed,  or  deployable  releases. 

To  modify  compatibility  data,  the  logic  planning  option  is  selected  from  the  AAS 
ATC  Operational  Support  and  Tracking  Menu. 

C.2.4  Update  Release  Tracking  Status  to  "RESOLVE.  Submit". 

Once  a  change  has  been  Implemented,  the  appropriate  release  and  the  RTR  associated 
with  the  ACI  are  updated  with  resolution  information.  The  status  is  updated  to 
"RESOLVE,  Submit"  to  notify  the  integration  test  organization  that  the  change  is 
ready . 

C.2.? _ Promote  Code  to  Integration  Level. 

After  all  changes  for  a  release  have  been  implemented,  the  Builds  and  Controls 
organization  (ACN-600)  is  notified  to  build  and  promote  the  release  to  the  INT. 

This  provides  a  controlled,  unmodifiable  set  of  code  to  the  Integration  testers 
for  testing. 

The  SCIM  software  performs  the  promote  fxmction  and  generates  a  discrepancy  report. 
This  report  contains  a  comparison  between  the  logic  release  plan,  including  the  ACI 
nvimbers  and  the  components  listed  for  each  ACI,  and  the  code  that  is  about  to  be 
promoted.  The  SCLM  identifies  each  component  to  be  promoted  and  each  ACI 
associated  with  that  component.  If  SCLM  tries  to  promote  any  component  or  ACI  that 
is  not  in  the  logic  release  plan,  a  discrepancy  is  flagged.  Likewise,  if  any 
components  or  ACIs  in  the  plan  are  not  in  the  SCLM  list,  the  discrepancy  is 
flagged.  Any  discrepancy  will  halt  the  promotion  unless  the  person  requesting  the 
promotion  has  the  authority  to  promote  with  discrepancies. 

To  promote  code  to  the  integration  level,  the  Library  Control  option  is  selected 
from  the  AAS  Administration  and  System  Support  Menu. 

C.2.6  Initiate  Test  Trackinz  Records. 

Test  tracking  data  is  information  about  a  test  that  is  run  to  verify  the 
Implementation  of  an  ACI.  Test  tracking  data  is  Informational  and  has  no  effect  on 
the  ACI  life  cycle. 

The  information  in  the  test  tracking  record  includes  the  ACI  number,  logic  release 
ID  (if  appropriate),  and  increment  ID  (if  appropriate)  associated  with  the  test; 
scheduling  and  assignment  information;  a  description  of  the  test;  and  the  test 
status . 

To  initiate  a  test  tracking  record,  the  Test  Tracking  option  is  selected  from  the 
AAS  ATC  Operational  Support  and  Tracking  Menu. 
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C.3  SYSTEM  RELEASE  PLANNING. 


After  the  operational  logic  has  been  modified  and  Is  ready  to  be  tested  on  the  SSF, 
a  system  release  plan  must  first  be  created.  The  system  release  plan  combines  the 
logic  with  constructed  adaptation  data  products.  The  system  release  plan  Is  test 
shipped  to  the  SSF  for  testing.  Appendix  B  describes  the  system  release  plan  In 
detail. 

£*3.1 _ Schedule  a  SSF. 

The  software  developer  schedules  the  SSF  to  test  the  system  release.  The  SSF 
scheduling  Is  performed  using  the  Resource  Scheduler  CAS  product.  ACN-600  Is 
responsible  for  the  scheduling  of  SSCC  resources.  Section  4.1.8  provides  resource 
scheduling  Information. 

£.3.2 _ Create  a  Logical  Replication  for  Simulation. 

To  create  a  site  simulation,  a  cumulative  system  release  must  be  constructed  to 
Include  the  modified  software,  the  adaptation  data  which  tailors  the  software,  and 
test  scenarios  to  exercise  the  software,  among  other  parameters.  The  test 
scenarios  will  Include  tests  to  determine  If  the  problem  or  change  Identified  by 
the  ACl  has  been  fixed  or  updated  as  well  as  regression  tests  to  ensure  that  the 
rest  of  the  system  Is  still  Intact. 

The  SSF  Managers  Organization  Is  responsible  for  configuring  SSCC  resources  to 
support  simulation  and  testing.  Once  the  software  and  hardware  requirements  for  a 
SSF  are  determined,  and  a  test  organization  makes  a  request  for  resources,  the  F&SC 
Operator  can  configure  the  hardware  for  a  SSF.  After  ^e  hardware  configuration 
has  been  set,  the  F&SC  Operator  prepares  the  software  configuration. 

Many  different  support  software  and  nonsupport  software  options  are  used  to 
configure  and  manage  the  equipment  and  test  systems. 

£.3.3 _ Execute  Integration  Tests. 

Once  the  SSF  Is  configured,  the  logic  release  Is  downloaded  to  the  support  facility 
for  Integration.  If  any  problems  are  found,  new  problem  ACIs  are  opened  and 
testing  continues. 

Any  problem  ACIs  that  are  opened  at  this  stage  follow  the  normal  ACI  life  cycle 
described  In  appendix  A.  They  are  screened  and  assigned  to  a  logic  release  for 
Implementation.  If  the  ACIs  are  assigned  to  the  current  logic  release,  they  will 
be  folded  Into  the  next  build  of  the  system  starting  at  the  "Define  the  Contents  of 
a  Logic  Release"  task. 

C.3. 4  Test  Completion. 

When  the  Integration  tester  Is  satisfied  that  the  updates  to  the  system  are 
working,  the  test  tracking  record(s)  associated  with  the  ACI  are  closed,  the  status 
of  the  RTR  Is  changed  to  "INTEGRAT,  Pass."  This  lets  the  formal  test  organization 
know  that  the  system  is  ready  for  formal  testing. 
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When  all  RTRs  for  the  logic  release  under  test  has  a  status  of  "INTEGRAT,  Pass," 
Build  and  Controls  organization  can  promote  the  code  to  the  REL  of  the  hierarchy. 
The  release  level  is  the  sane  as  the  formal  test  level.  A  discrepancy  report  will 
be  generated  at  this  step.  Any  discrepancies  found  will  prevent  the  promotion 
without  special  authority. 

C.3.4.2 _ Close  the  Logic  Release. 

A  logic  release  is  closed  and  baseline.  Closing  the  logic  release  sets  the  logic 
release  status  to  CLOSED.  Any  open  logic  release  plan  may  be  closed  except  for 
operational  logic  releases,  which  may  not  be  closed  unless  a  compatible  support 
software  release  has  been  Identified  by  modifying  the  compatibility  data.  Once  a 
logic  release  plan  is  closed,  it  may  not  be  reopened,  and  can  be  modified  only  to 
the  extent  that  compatibility  data  may  be  changed. 

To  close  a  logic  release,  the  Logic  Planning  option  is  selected  from  the  AAS  ATC 
Operational  and  Change  Tracking  Menu. 

C.3.4.3  Set  the  Logic  Release  Status  to  "DEPLOY" 

After  a  logic  release  has  been  promoted  to  the  release  level  of  the  hierarchy,  is 
fully  tested,  and  has  a  status  of  CLOSED,  the  logic  release  status  is  changed  to 
DEPLOY.  The  logic  release  status  mixst  be  DEPLOY  before  any  system  release  that 
references  this  logic  release  can  be  deployed.  If  necessary,  a  logic  release 
status  may  be  changed  back  to  CLOSED  if  it  has  not  actxxally  been  deployed. 

To  set  the  logic  release  to  DEPLOY,  the  Logic  Planning  option  is  selected  from  the 
AAS  ATC  Operational  Support  and  Tracking  Menu. 

C. 3.4.4  Generate  the  Logic  Release  VDD  Reports. 

The  primary  document  that  accompanies  each  logic  release  is  the  Version  Description 
Document  (VDD) .  This  document  is  unique  to  each  site  that  is  to  receive  the 
release  and  Includes  information  concerning  the  logic  release,  such  as  an  inventory 
list  of  adaptation  data  products  and  ACIs  associated  with  the  release. 

Once  the  logic  release  is  complete,  the  reports  related  to  the  logic  release  are 
Included  in  the  VDD.  These  reports  are  saved  for  later  Inclusion  in  the  VDD 
generated  for  a  particular  system  release. 
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